Active Directory FAQ

What are advance audit policy settings?

2012-02-17T00:54:00.000-08:00

In Windows 7 and Windows Server 2008 R2, the number of audit settings for which success and failure can be tracked has increased to 53. Previously, there were nine basic auditing settings under Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Audit Policy. These 53 new settings allow you to select only the behaviors that you want to monitor and exclude audit results for behaviors that are of little or no concern to you, or behaviors that create an excessive number of log entries. In addition, because Windows 7 and Windows Server 2008 R2 security audit policy can be applied by using domain Group Policy, audit policy settings can be modified, tested, and deployed to selected users and groups with relative simplicity.

Please read this article for more details

Can you roll back Forest functional level of Windows 2008 R2?

2012-02-17T00:51:00.000-08:00

After you set the forest functional level to a certain value in Windows Server 2008 R2, you cannot roll back or lower the forest functional level, with one exception: when you raise the forest functional level to Windows Server 2008 R2 and if the Active Directory Recycle Bin is not enabled, you have the option of rolling the forest functional level back to Windows Server 2008. For more information about the Active Directory Recycle Bin, see What's New in AD DS: Active Directory Recycle Bin (http://go.microsoft.com/fwlink/?LinkId=141392). You can lower the forest functional level only from Windows Server 2008 R2 to Windows Server 2008. If the forest functional level is set to Windows Server 2008 R2, it cannot be rolled back to Windows Server 2003, for example.

For more details on forest Functional Level Please read this article.

What are Group Policy preferences in Windows 2008?

2012-02-17T00:43:00.000-08:00

Group Policy preferences that are new in Windows Server 2008 and how to enable down-level computers to process these new items. Group Policy preferences are made up of more than 20 new Group Policy client-side extensions (CSEs) that expand the range of configurable settings in a Group Policy object (GPO). These new preference extensions are included in the Group Policy Management Editor window of the Group Policy Management Console (GPMC). The kinds of preference items that can be created by using each extension are listed when New is selected for the extension. Examples of the new Group Policy preference extensions include the following:

Folder Options
Drive Maps
Printers
Scheduled Tasks
Services
Start Menu

For more details please read this KB Article.

Download the Microsoft Doc file from here.

Explain Managed Service Accounts in Active Directory.

2012-02-15T12:17:00.000-08:00

A new feature to manage service accounts in Windows 7 and Windows Server 2008 R2 to help you maintain and secure your IT environment.

Managed service accounts in Windows Server 2008 R2

Background
One of the security challenges for critical network applications is selecting the appropriate type of account for the application to run as:

On a local computer, an administrator can configure the application to run as Local Service, Network Service, or Local System. These service accounts are simple to configure and use, but they are typically shared among multiple applications and services and cannot be managed on a domain level.
If you configure the application to use a domain account, you can isolate the privileges for the application. However, you need to manually manage passwords or create a custom solution for managing these passwords.

Overview of the managed service account
The managed service account is designed to provide applications such as SQL Server or Exchange with:

Automatic password management, which can better isolate these services from other services on the computer.

Important
The default password refresh behavior for the managed service account is to be automatically updated every 30 days. However, this can cause a failed authentication attempt because the NTLM and Kerberos security support providers will not recognize the new password. To rectify this problem permanently, install the hot fix as described in the knowledge base article “Managed service account authentication fails after its password is changed in Windows 7 or in Windows Server 2008 R2 (KB 2494158).”

Important

The default password refresh behavior for the managed service account is to be automatically updated every 30 days. However, this can cause a failed authentication attempt because the NTLM and Kerberos security support providers will not recognize the new password. To rectify this problem permanently, install the hot fix as described in the knowledge base article “Managed service account authentication fails after its password is changed in Windows 7 or in Windows Server 2008 R2 (KB 2494158).”

Simplified service principal name (SPN) management, which allows service administrators to set SPNs on these accounts. In addition, SPN management can be delegated to other administrators.

Management
To configure and manage these accounts for a service running on Windows 7 or Windows Server 2008 R2, you will need to use Windows PowerShell cmdlets. There is no UI support for creating and managing these accounts.
Service accounts are also supported on Windows Server 2003 and Windows Server 2008 domain controllers. For information about these requirements and additional configuration steps, see Managed Service Accounts Step-by-Step Guide.

Resources for managed service accounts

For information about how to set up managed service accounts, see Managed Service Accounts Step-by-Step Guide.

What is NTLM Blocker in Active Directory in Windows 2008?

2012-02-15T12:11:00.000-08:00

Q. What is NTLM Blocker in Windows 2008 R2 and Windows 7?
Q. How does it work?
Q. Can we have any kind of exclusion?

New Group Policy settings in Windows 7 and Windows Server 2008 R2 permit the restriction of NTLM protocol usage on clients, servers, and domain controllers. These policies can be configured on computers running Windows 7 and Windows Server 2008 R2, which can affect NTLM usage on computers running earlier versions of Windows.
The following Security Option settings can be configured to help you restrict NTLM usage in your environment.

Network Security: Restrict NTLM: Incoming NTLM Traffic
Network Security: Restrict NTLM: NTLM authentication in this domain
Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers

To know more click here

Active Directory restore and backup

2011-03-13T23:39:00.000-07:00

Non-authoritative restore of Active Directory
A non-authoritative restore returns the domain controller to its state at the time of backup, then allows normal replication to overwrite that state with any changes that have occurred after the backup was taken. After you restore the system state, the domain controller queries its replication partners. The replication partners replicate any changes to the restored domain controller, ensuring that the domain controller has an accurate and updated copy of the Active Directory database.

Non-authoritative restore is the default method for restoring Active Directory, and you will use it in most situations that result from Active Directory data loss or corruption. To perform a non-authoritative restore, you must be able to start the domain controller in Directory Services Restore Mode.

Authoritative restore of Active Directory
An authoritative restore is an extension of the non-authoritative restore process. You must perform the steps of a non-authoritative restore before you can perform an authoritative restore. The main difference is that an authoritative restore has the ability to increment the version number of the attributes of all objects in an entire directory, all objects in a subtree, or an individual object (provided that it is a leaf object) to make it authoritative in the directory. Restore the smallest unit necessary, for example, do not restore the entire directory in order to restore a single subtree.

As with a non-authoritative restore, after a domain controller is back online, it will contact its replication partners to determine any changes since the time of the last backup. However, because the version number of the object attributes that you want to be authoritative will be higher than the existing version numbers of the attribute held on replication partners, the object on the restored domain controller will appear to be more recent and therefore will be replicated out to the rest of the domain controllers within the environment.

Unlike a non-authoritative restore, an authoritative restore requires the use of a separate tool, Ntdsutil.exe. No backup utilities— including the Windows 2000 Server system tools— can perform an authoritative restore.

An authoritative restore will not overwrite new objects that have been created after the backup was taken. You can authoritatively restore only objects from the configuration and domain-naming contexts. Authoritative restores of schema-naming contexts are not supported.

Perform an authoritative restore when human error is involved, such as when an administrator accidentally deletes a number of objects and that change replicates to the other domain controllers and you cannot easily recreate the objects. To perform an authoritative restore, you must start the domain controller in Directory Services Restore Mode.

If you wish to read more and know more about active directory restore and backup, please read this article.

Troubleshooting AD Replication

2011-03-11T06:26:00.000-08:00

Replication is another common AD trobleshooting scenario.
AD replication issues usually turn out to be caused by one of the following:

a) Faulty, substandard or misconfigured network equipment or WAN links
b) USN rollback issues caused by using unsupported restore methods (disk imaging of DC's, P2V utilities, snapshots, etc.)
c) DNS issues
d) Lingering objects

Further reading is available at "Troubleshooting AD Replication"

How to detect and recover from a USN rollback in Windows Server 2003
How to detect and recover from a USN rollback in Windows 2000 Server
Domain controllers do not demote gracefully when you use the Active Directory Installation Wizard to force demotion in Windows Server 2003 and in Windows 2000 Server
How to remove data in Active Directory after an unsuccessful domain controller demotion

What happens in a Journal Wrap?

2011-03-11T06:18:00.000-08:00

FRS is a multi-master replication system that takes care of replicating the contents of Sysvol between all DC’s in the domain (it can also replicate normal data but we're primarily interested in Sysvol replication in the blog entry).
With proper care and maintenance, Post-SP2 FRS on W2k3 is pretty stable and happily hums along as long as there isn’t an external condition such as a network outage or disk problems that cause it to break down (assuming the data you're replicating isn't completely unsuitable for replicating like .PST files, profile data or content that changes frequently).

The most frequent FRS issue is where a Journal Wrap occurs; let’s take a closer look at what happens during a Journal Wrap under the hood.

The way FRS works is that it has an internal database that contains all the files and folders it is replicating and each of these has a unique global ID (GUID). The dababase also contains a pointer to the last NTFS disk operation (in the USN Journal/NTFS Journal) that the FRS service processed.

If a user changes a file or folder on a disk, the following happens:
1) the operation is picked up by NTFS and an entry is made in the NTFS Journal
2) FRS monitors the NTFS Journal for changes and notes that a change has been made to that file
3) FRS keeps a record of the last NTFS Journal event that it processed and checks if it has processed it already
4) If it hasn’t processed it already, it looks at whether it is a file that it should replicate
5) If it should be replicated, the file goes into the normal process of staging, replicating, etc.
6) FRS increments the entry in its database about the NTFS Journal event that it has processed so it won’t consider it again

Now…let’s simplify things a bit.
- Our disk contains one file and one folder (e:\Test and test.txt)
- Our NTFS journal has a size of 10 entries (default NTFS Journal size in RL is ~512 Mb depending on your OS/SP level)
- Our FRS database contains three entries
o a GUID for E:\test
o a GUID for E:\test\test.txt
o A referral to the last NTFS Journal entry we processed (let’s say #4)
Normal operations:
- someone makes a change to test.txt
o the NTFS Journal is updated to #5
o FRS notes that the NTFS journal says that a change has been made to test.txt and it sees that it hasn’t processed that change
o Stage/Replicate and update the FRS database to reflect that we have processed that NTFS Journal entry.
Now, an Admin stops the FRS service for 30 minutes….
- Someone makes 10 changes to test.txt
o The NTFS Journal is updated 20 times and is now at #24 (remember we have a log size limit of the last 10 entries so therefore need to wrap around)
o FRS is stopped so it isn’t monitoring the NTFS Journal log
At this point, we have changes on the disk which FRS isn’t aware of. FRS still knows the last NTFS Journal entry that it processed and it will compare this with the current NTFS Journal the next time it restarts.
The next time the FRS service starts, it sees that it has missed NTFS operations on the disk (it last processed NTFS operation #4 but the NTFS Journal is now at #24 and we only have a log that goes back 10 entries so we’re missing operations #5-#14 from the database.
This is when FRS complains it has reached a Journal Wrap state, the NTFS Journal log has wrapped around and it doesn’t know the current state of things on the disk.
The impact of this on an affected DC is that FRS will not set the IsSysvolReady registry key to indicate to the Netlogon service that all is well, Sysvol will therefore not be shared out and the DC will not be able to authenticate users fully until the Journal Wrap condition has been resolved.
Manually sharing out Sysvol or setting the IsSysvolReady registry key to 1 are not valid methods of resolving this issue and are not addressing the real problem.

For FRS to recover from a Journal wrap, you’ll basically have to start from scratch and reset the FRS database and start counting the NTFS Journal from the current values it has.
This means either:
- Replicating in data from an existing inbound partner (The d2 or non-authoritative FRS restore approach)
- Making your own data authoritative and let everyone else replicate from you (the d4 or authoritative FRS restore approach)

The d2 approach is fairly simple to perform, the requirements are however that you have a good network connection with the inbound replication partner and the time it will take is dependent on the amount of data to be replicated vs. the capacity of the link

On the other hand, this may not always be sufficient and you can find yourself being forced to go with the d4 option. Going with the d4 approach should always be a last resort, it’s a time-consuming operation that requires careful planning and co-ordination between all DC's and they will be more or less inoperative during that time as the FRS service has to be stopped on each and only restarted gradually as the operation progresses. This is especially important for DC’s as they will have a hard time servicing users without a proper Sysvol being present.
For a full description of the d2/d4 burflags and how to use them, See KB 290762.

Further reading:
Troubleshooting journal_wrap errors on Sysvol and DFS replica sets
Using the BurFlags registry key to reinitialize File Replication Service replica sets
How to rebuild the SYSVOL tree and its content in a domain
Monitoring and Troubleshooting the File Replication Service
Why is placing the Sysvol directory on a separate partition a good practice?
Troubleshooting File Replication Service

Upgrading Windows NT 4.0 domain to Windows 2008 domain

2009-11-26T05:47:00.000-08:00

Migration for NT 4.0 Domain to Windows Server 2008 Domain
Upgrading WinNT 4.0 domain to Windows 2008 domain
How to upgrade WINNT 4.0 domain to Windows 2008 domain.

We cannot directly upgrade Windows NT4.0 domain to Windows Server 2008 domain.

In order to smoothly upgrade the domain, here are two recommended upgrade
routes for your reference.

Route 1.

A. Upgrade Windows NT 4.0-Based PDC to Windows Server 2003-Based domain
controller.

For more detail steps, please refer to:

How To Upgrade a Windows NT 4.0-Based PDC to a Windows Server 2003-Based
Domain Controller
http://support.microsoft.com/kb/326209

Moving from Windows NT 4.0 Server to Windows Server 2003
http://download.microsoft.com/download/2/c/3/2c3cc747-a843-4a23-b665-8bd62fa
bbc1e/How-to-Migrate-from-NT-to-WS2003.pdf

B. Then upgrade Windows Server 2003 based domain to Windows Server 2008
domain.

For more detail steps, please refer to:

Upgrading Active Directory Domains to Windows Server 2008 AD DS Domains
http://technet2.microsoft.com/windowsserver2008/en/library/9c91be5f-df14-40b
2-b176-2b1852a51e611033.mspx?mfr=true

Route 2.

We may also use ADMT 3.1 to migrate from Windows NT 4.0 source domain to
Windows Server 2008 domain.

Since ADMT 3.1 Beta has been available for public evaluation. If you are
interested, please refer to the steps provided in the following below link
to apply for ADMT 3.1 Beta.

ADMT 3.1 Beta
http://blogs.technet.com/ad/archive/2008/04/22/admt-3-1-beta.aspx