Articles

Current Articles | Categories | Search | Syndication

Active Directory FAQs

By SuperUser Account on Tuesday, December 18, 2007 10:34 AM

0 Comments

This FAQ attempts to answer some of the most common questions around the subject of Active Directory.

1. ADUC shows only 2000 objects. How can I see more?

When viewing objects in Active Directory Users and Computers you may come across the default folder display limit of 2000 objects. To adjust this, select Filter Options from the View menu. Change the Maximum number of items displayed per folder setting to a new value.

2. How can I rename my AD domain?

The short answer to this is, "you can't" if you have Windows 2000 Active Directory, unless you are running in mixed mode. Even in mixed mode it is a major headache. The following Microsoft KB article explains the limitations as well as the procedure: http://support.microsoft.com/kb/292541/en-us

A domain rename is possible with Windows Server 2003 AD domains (they even have a tool for it), although there are a few limitations. In a Windows Server 2003 forest, you cannot:

Change which domain is the forest root domain. Changing the DNS or the NetBIOS name of the forest root domain, or both, is supported.
Drop domains from the forest or add domains to the forest. The number of domains in the forest before and after the rename/restructure operation must remain the same.
Rename a domain with the same name that another domain gave up in a single forest restructure operation.

For more information about domain renaming in Windows Server 2003 AD, see the following link:

http://www.microsoft.com/technet/downloads/winsrvr/domainrename.mspx

Domain renames become more complicated (but not impossible) if you have Exchange running in the forest. See the following blog entry for more information.

http://blogs.technet.com/exchange/archive/2004/08/30/222719.aspx

3. Why isn't the lastLogoff attribute value set?

If you query an Active Directory domain controller you will notice that the lastLogon attribute value is set, but not the lastLogoff attribute. It appears that the lastLogoff attribute is not supported in Active Directory, either in Windows 2000 or Windows Server 2003.

I have not been able to find any Microsoft documentation that explains this.

4. Is it possible to get the "Active Directory Users and Computers" tool without promoting this machine to a domain controller?

Yes. All you need to do is add the snap-in to your MMC. The components are installed along with Windows 2000 or 2003 Server. On domain controllers, the installation process actually creates MMC's for those, but on a member server, the MMC's are not created automatically.

To get the tool working for Windows XP, download the Windows Server 2003 Administration Tools Pack (adminpak.msi) from the Microsoft download web site:

http://www.microsoft.com/downloads/details.aspx?FamilyID=C16AE515-C8F4-47EF-A1E4-A8DCBACFF8E3&displaylang=en

Running the adminpak.msi package file on either Windows Server or XP, will get you all of the admin tools with nice shortcuts created in your programs menu. Also make sure you read the Service Pack release documentation for any updates to adminpak.msi.

5. Is it necessary to install and configure DNS before setting up the Active Directory?

No, you can do it after for the First DC in the forest - you will need DNS installed and configured to install additional DCs. However, for proper functionality of Active Directory you will need to configure DNS as soon as possible after the installing Active Directory.

6. Are there any Windows 95/98/ME tools to administer active directory?

No, but there are tools available for Windows 2000 Professional and Windows XP. Remote Desktop Connection (Terminal Services) client is another alternative.

7. How do I enable diagnostic logging for Active Directory Services?

See http://support.microsoft.com/?id=314980

8. How do I view email properties for users, etc. in the Active Directory Users and Computers snap-in?

Short answer:

You need the Exchange 2000 or 2003 version.

Long answer: The menu item referred to by Programs -> Microsoft Exchange -> Active Directory Users and Computers is just a slightly customized version of the dsa.msc in the System32 folder. The only difference between the Exchange MSC file (users and computers.msc) and the existing dsa.msc console is that it customizes the columns to include "E-mail Address", "Exchange Alias", "Exchange Mailbox", and "Modified." Items like "Exchange Tasks..." and e-mail properties are available to any console that uses the AD Users and Computers snap-in, as long as the Exchange System Management tools have been loaded on the local machine. You can continue to use the regular AD Users and Computers snap-in from whatever location you execute it from - Programs -> Administrative Tools, or Control Panel -> Administrative Tools, or your own customized MMC documents. If you like having the "E-mail Address" column display, use View -> Choose Columns to add it and any others you want. The Exchange-specific stuff, like property pages on Users, the "Exchange Tasks" wizard, and the additional wizard pages are added by the Exchange 2000/2003 setup program. During the Schema Extension portion of Exchange setup, Active Directory is given the GUIDs for all the Exchange user interface elements. These are stored (mostly), in displaySpecifiers in the Configuration portion of the directory. The portion of Exchange setup that puts its administrative tools on a desktop goes ahead and puts the GUIDs in the local computers registry and copies the various DLLs that provide that UI support for Exchange objects and Exchange extended objects. Bottom line: You're not forced to use the Programs -> Microsoft Exchange -> Active Directory Users & Computers menu item. However, it is critical that you have installed the ADMINPAK.MSI, and the Microsoft Exchange System Management tools (from the Exchange 2000/2003 setup program.

9. How can I setup AD to allow anonymous searches?

By default LDAP searches are enabled (but restricted) in Windows 2000 AD, but disabled in Windows Server 2003 AD. One method to allow anonymous searches is to grant READ permissions to the "Everyone" group on the relevant container(s). You must grant it from the root of the directory down to the container(s) of interest.

10. Is AD susceptible to virus attacks and should I be doing something about it?

It is important to maintain a level of security, including physical security, commensurate with the potential threats. AD is no more susceptible to attacks than any other directory, and arguably less susceptible than many (by denying access to anonymous users by default, for example).Trojans that propagate by reading address book entries and e-mailing themselves can propagate themselves more widely if the "Address book" lists everyone in an enterprise, but this is not AD-specific: any corporate address book represents a risk. A good anti-virus scanner will catch these before a user can trigger them.You should talk to your Anti-virus software supplier about a file exclusion list for Active Directory domain controllers. If they don't offer one, here is a suggestion:

Back to Top

ntds.dit--The database
edb.chk--Checkpoint file
edb*.log--Transaction log files
res1.log and res2.log--Reserved transaction log files (used in case the server runs out of hard disk space)
SYSVOL - System Volume

For more information about the dangers of including SYSVOL when virus scanning, see the following Knowledge Base article.Antivirus Problems May Modify Security Descriptors Causing Excessive Replication of FRS Data in Sysvol and DFS (Q284947)

11. Some of the object properties do not appear in the user interface. How can I access them to set permissions?

Not every property of an object is listed in the Active Directory Users and Computers interface. The number of properties is quite large so the interface only displays those that are commonly used for controlling access. This makes the list easier to manage.The list of filtered object types and properties is kept in the file, %systemroot%\System32\Dssec.datYou can modify the behavior of the filter by changing the values associated with the properties. For example, if you wanted to delegate the right to unlock accounts you can do this by changing the value of the lockoutTime entry in the [user] section of the file from lockoutTime=7 to lockoutTime=0.You have the following choices to specify values:Property=7: The property is not included.Property=6: "Read property" is included. Property=5: "Write property" is included.Property=0: Both "Read property" and "Write property" are included.The property is not included in DSSec.Dat: Both "Read property" and "Write property" are included.You must modify the Dssec.dat file on the computer on which you are running ADUC. It is a good idea to make a copy of the file first before making any changes.For further reading on this, please see the following Microsoft documents:Access Control How To Delegate the Unlock Account Right (Q294952)

12. Is an Active Directory Management Pack available for MOM 2005?

Yes.

The Microsoft Active Directory Management Pack Guide can be downloaded here: http://www.microsoft.com/downloads/details.aspx?FamilyID=B516E614-814A-4277-ABF9-8D5315D2BA06&displaylang=en

13. How should I test schema changes?

Schema updates are a necessary evil to support new features or applications within your AD forest. Because of the potential for schema conflicts that can cause problems or loss of functionality, you should ensure that you thoroughly test and document your changes before putting them anywhere near your production forest.Keep a change log for all the changes made to your schema. A good way to do this is to maintain a copy of all the changes in LDIF format. Most reputable vendors will be able to provide you with the required LDIF files (although it sometimes takes some pushing). One advantage of the LDIF format is that it is human readable, so you can look through the changes and assess the impact before even putting them into your test lab. A second advantage is that you can use the LDIF files to import the schema changes in your test lab.It’s a good idea to maintain a physically separate test AD lab on an ongoing basis. This will not only allow you to test schema changes, but will give you an environment in which to test new applications, migrations, Group Policy changes and to assist with problem troubleshooting. The AD forest in the test lab should be at the same schema level as your production forest. If the two environments are not in-step then any schema testing may not produce accurate results.The use of virtual machines is helpful in the test lab. For example, the use of the snapshot feature within VMWare allows you to take a snapshot of the system, make your changes and then (if necessary) roll-back to the snapshot. This is especially helpful when testing home grown schema changes.If you find yourself in an environment that does not have a working test lab and you have an urgent need to test a schema change before implementation, here are some suggested steps to extract a copy of a DC from the production forest for testing purposes.

Create a new site in AD and use the DC Locator DNS records not registered by the DCs Group Policy to prevent authentication requests being serviced by the DCs in the site (more detail on how to do this here: http://searchwin2000.techtarget.com/tip/1,289483,sid1_gci1086805,00.html?bucket=ETA)
Add a new virtual (e.g. VMWare) member server to the forest root domain and place it in the new site.
Run dcpromo to make it a DC.
Wait for replication to complete to this DC.
Shut down the DC.
Save a copy of the virtual machine.
Start the DC you shut down in Step 5.
Demote it to a member server.
Remove the member server from the network.
Put the DC copy (from Step 6) onto your test network and start it.
Seize the FSMO roles to this DC. See this KB for more detail on this http://support.microsoft.com/kb/255504
Perform schema update tests as required.

Warning: Making copies of your production DCs is risky from a security perspective. You should always maintain the physical security of your DCs. Also give thought to the procedures you need to put in place to ensure that any virtual machine copies of DCs never get put back into production by accident. Once your tests are complete and are positive, you should still perform a safe schema update in production, by putting the schema FSMO and another DC into a lag site. This allows you to ensure that the schema changes are performed successfully (including replication to a partner DC) within the lag site, prior to forcing the change outside the lag site and updating all other DCs in the forest. If something goes wrong, you only need to restore the LAG site DCs/GCs.

14. If no Domain Controllers are available within a site, will clients failover to Domain Controllers in the closest available site?

No. Although you might expect this to be the case, if a client can't find a DC in its site, it will then try to find any DC in its domain, regardless of site, based on the weights and priorities associated with the DCs' locator records in DNS. Site link cost doesn't enter into the process.

Clients generally always try to use a DC in their own site. The DNS query for this is:

_ldap._tcp.<SITE>._sites.dc._msdcs.<domain>.<tld>

If no DCs respond to the reques then the client will attempt to find a DC using a different DNS query, as follows:

_ldap._tcp.dc._msdcs.<domain>.<tld>

As you can see, there is no site-specific information in the second query, which means that any DC in the domain can potentially be returned in the results.

One useful option is to consider not registering the generic domaini records for any DCs that are in branch offices. This way you will ensure that your datacentre DCs will be used in failover situations (as well as for initial DC location). This will ensure a quicker failover, since the list of DCs passed to the client when performing a generic domain DC query is also much quicker (all DCs in the list will be pinged by the client to check which one responds first).

See the following KB article for more information about how to control the locator records.

http://support.microsoft.com/kb/306602

15. I need to disable replication for a Domain Controller. How can I do this?

To disable outbound replication for a particuar DC, use the following command:

repadmin /options <dc name> +DISABLE_OUTBOUND_REPL

This can be helpful, for example, when extending the AD schema and you want to run some checks against the DC holding the Schema Master FSMO Role to ensure that all looks good before allowing the changes to replicate out.

To re-enable outbound replication, run:

repadmin /options <dc name> -DISABLE_OUTBOUND_REPL

Note that disabling outbound replication for a DC will not stop changes from being replicated to the DC from its replication partners.

To disable inbound replication for a particular DC, use the following command:

repadmin /options <dc name> +DISABLE_INBOUND_REPL

This can be useful in recovery situations in which you have accidentally deleted an object (e.g. OU) and you find that one of your DCs in a remote site has not yet received the change. If you stop inbound replication on this DC you have the ability to authoritatively restore the deleted OU.

To enable inbound replication, run:

repadmin /options <dc name> -DISABLE_INBOUND_REPL

One further option is to stop replication for the entire forest (aka Hitting the Panic Button). To do this, use the following (undocumented) option:

repadmin /options * +DISABLE_INBOUND_REPL

Note: Think carefully about the consequences of using this option before you do it!

To enable replication again, run:

repadmin /options * -DISABLE_INBOUND_REPL

For more information about the uses of repadmin to disable replication, see the KB articles 321163 and 840001.

Comments

Currently, there are no comments. Be the first to post one!
Click here to post a comment

Your Home Page ..

Site Articles:

Mail List Posts:

Friends

Articles

Active Directory FAQs

Friends

Articles

Related Links

Ads