Windows Management and Scripting

A wealth of tutorials Windows Operating Systems SQL Server and Azure

Posts Tagged ‘Active Directory’

Active Directory Recycle Bin

Posted by Alin D on November 11, 2012

When your Active Directory forest is operating in the Windows Server 2008 R2 or higher mode, you can use the Active Directory Recycle Bin. The Active Directory Recycle Bin adds an easy-to-use recovery feature for Active Directory objects. When you enable this feature, all link-valued and non-link-valued attributes of a deleted object are preserved, allowing you to restore the object to the same state it was in before it was deleted. You can also recover objects from the recycle bin without hav- ing to initiate an authoritative restore. This differs substantially from the previously available technique, which used an authoritative restore to recover deleted objects from the Deleted Objects container. Previously, when you deleted an object, most of its non-link-valued attributes were cleared and all of its link-valued attributes were removed, which meant that although you could recover a deleted object, it was not restored to its previous state.

Preparing Schema for the Recycle Bin

Before you can make the recycle bin available, you must update Active Directory schema with the required recycle bin attributes. You do this by by preparing the forest and domain for the Windows Server 2008 R2 functional level or higher. When you do this, the schema is updated, and then every object in the forest is updated with the recycle bin attributes as well. This process is irreversible once it is started.

After you prepare Active Directory, you need to upgrade all domain control- lers in your Active Directory forest to Windows Server 2008 R2 or higher and then raise the domain and forest functional levels to the Windows Server 2008 R2 level or higher. Optionally, you can update Active Directory schema in your forests and domains for Windows Server 2012 to enable the enhanced recycle bin.

After these operations, you can enable and access the recycle bin. Once Recycle Bin has been enabled, it cannot be disabled. Now when an Active Directory object is deleted, the object is put in a state referred to as logically deleted and moved to the Deleted Objects container. Also, its distinguished name is altered. A deleted object remains in the Deleted Objects container for the period of time set in the deleted object lifetime value, which is 180 days by default.

NOTE: The msDS-deletedObjectLifetime attribute replaces the tombstone- Lifetime attribute. However, when msDS-deletedObjectLifetime is set to $null, the lifetime value comes from the tombstoneLifetime. If the tombstoneLifetime is also set to $null, the default value is 180 days.

 

Recovering Deleted Objects

If you elect not to use the recycle bin, you can still recover deleted objects from the Deleted Objects container by using an authoritative restore and other techniques I’ll discuss in this section. The procedure has not changed from previous releases
of Windows Server. What has changed, however, is that the objects are restored to their previous state with all link-valued and non-link-valued attributes preserved. To perform an authoritative restore, the domain controller must be in Directory Services Restore Mode.

Rather than using an authoritative restore and taking a domain controller offline, you can recover deleted objects by using the Ldp.exe administration tool or the Ac- tive Directory cmdlets for Windows PowerShell. If you updated the Active Directory schema in your forests and domains for Windows Server 2012, you also can enable the enhanced recycle bin, which allows you to recover deleted objects using Active Directory Administrative Center.

Keep in mind that Active Directory blocks access to an object for a short while after it is deleted. During this time, Active Directory processes the object’s link-value table to maintain referential integrity on the linked attribute’s values. Active Direc- tory then permits access to the deleted object.

Using Ldp.exe for Basic Recovery

You can use Ldp.exe to display the Deleted Objects container and recover a deleted object by following these steps:

1. Type Ldp.exe in the Apps Search box, and then press Enter.

2. On the Options menu, tap or click Controls. In the Controls dialog box, select 
Return Deleted Objects in the Load Predefined list, and then tap or click OK.

3. Bind to the server that hosts the forest root domain by choosing Bind from the Connection menu. Select the Bind type, and then tap or click OK.

4. On the View menu, tap or click Tree. In the Tree View dialog box, use the BaseDN list to select the appropriate forest root domain name, such as DC=windows-scripting,DC=org, and then tap or click OK.

5. In the console tree, double-tap or double-click the root distinguished name and locate the CN=Deleted Objects container.

6. Locate and press and hold or right-click the Active Directory object you want to restore, and then tap or click Modify. This displays the Modify dialog box.

7. In the Edit Entry Attribute text box, type isDeleted. Do not enter anything in the Values text box.

8. Under Operation, tap or click Delete, and then tap or click Enter.

9. In the Edit Entry Attribute text box, type distinguishedName. In Values, 
type the original distinguished name of this Active Directory object.

  1. Under Operation, tap or click Replace. Select the Extended check box, tap or click Enter, and then tap or click Run.

Using Windows PowerShell for Basic and Advanced Recovery

The Active Directory cmdlets for Windows PowerShell allow you to recover deleted objects using scripts or by typing commands at a PowerShell prompt. You use Get- ADObject to retrieve the object or objects you want to restore, pass that object or objects to Restore-ADObject, and then Restore-ADObject restores the object or objects to the directory database.

NOTE The Active Directory module is not imported into Windows PowerShell by de- fault. Import the Active Directory module by typing import-module activedirectory at the PowerShell prompt. For more information, see “Active Directory Administrative Center and Windows PowerShell” in Chapter 7.

To use the Active Directory cmdlets for recovery, you need to open an elevated, administrator PowerShell prompt by pressing and holding or right-clicking the Windows PowerShell entry on the menu and tapping or clicking Run As Administra- tor. The basic syntax for recovering an object is as follows:

Get-ADObject -Filter {ObjectId} -IncludeDeletedObjects | Restore-ADObject

ObjectId is a filter value that identifies the object you want to restore. For ex- ample, you could restore a deleted user account by display name or SAM account name as shown in these examples:

Get-ADObject -Filter {DisplayName -eq "Rich Tuppy"} -IncludeDeletedObjects | Restore-ADObject

Get-ADObject -Filter {SamAccountName -eq “richt”} –IncludeDeletedObjects | Restore-ADObject

Note that nested objects must be recovered from the highest level of the deleted hierarchy to a live parent container. For example, if you accidentally deleted an OU and all its related accounts, you need to restore the OU before you can restore the related accounts.

The basic syntax for restoring container objects such as an OU is as follows:

Get-ADObject -ldapFilter:”(msDS-LastKnownRDN=ContainerID)” –IncludeDeletedObjects | Restore-ADObject

ContainerID is a filter value that identifies the container object you want to restore. For example, you could restore the Corporate Services OU as shown in this example:

Get-ADObject -ldapFilter:”(msDS-LastKnownRDN=Corporate_Services)”

–IncludeDeletedObjects | Restore-ADObject

If the OU contains accounts you also want to restore, you can now restore the ac- counts by using the technique discussed previously, or you can restore all accounts at the same time. The basic syntax requires that you establish a search base and associate the accounts with their last known parent, as shown here:

Get-ADObject -SearchBase “CN=Deleted Objects,ForestRootDN” -Filter {lastKnownParent -eq “ContainerCN,ForestRootDN“} -IncludeDeletedObjects | Restore-ADObject

ForestRootDN is the distinguished name of the forest root domain, such as DC=windows-scripting,DC=org, and ContainerCN is the common name of the container, such as OU=Corporate_Services or CN=Users. The following example restores all the ac- counts that were in the Corporate Services OU when it was deleted:

Get-ADObject -SearchBase “CN=Deleted Objects,DC=Cpandl,DC=com” –Filter

{lastKnownParent -eq “OU=Corporate_Services,DC=windows-scripting,DC=org”}

-IncludeDeletedObjects | Restore-ADObject

Using the Enhanced Recycle Bin for Recovery

The enhanced recycle bin makes recovering deleted objects as easy as pointing and clicking or tapping and holding. Once you updated the Active Directory schema
in your forests and domains for Windows Server 2012, you enable the enhanced recycle bin for use by following these steps:

1. In Active Directory Administrative Center, the local domain is opened for management by default. If you want to work with a different domain, tap or click Manage and then tap or click Add Navigation Nodes. In the Add Navigation Nodes dialog box, select the domain you want to work with and then tap or click OK.

  1. Select the domain you want to work with by tapping or clicking it in the left pane. In the Tasks pane, tap or click Enable Recycle Bin and then tap or click OK in the confirmation dialog box.
  2. Active Directory will begin replicating the change to all domain controllers in the forest. Once the change is replicated, the enhanced recycle bin will be available for use. If you then tap or click Refresh in Active Directory Adminis- trative Center, you’ll see that a Deleted Object container is now available for domains using the enhanced recycle bin.

Keep in mind that the enhanced recycle bin is a forestwide option. When you enable this option in one domain of a forest, Active Directory replicates the change to all domain controllers in all domains of the forest.

With the enhanced recycle bin enabled, you can recover deleted objects with ease. In Active Directory Administrative Center, domains using the enhanced recycle bin will have a Deleted Object container. In this container, you’ll see a list of deleted objects. As discussed previously, deleted objects remain in this container for the deleted object lifetime value, which is 180 days by default.

Each deleted object is listed by name, when it was deleted, the last known par- ent, and the type. When you select a deleted object by tapping or clicking it, you can use the options in the Tasks pane to work with it. The Restore option restores the object to its original container. For example, if the object was deleted from the Users container, it is restored to this container.

The Restore To option restores the object to an alternate container within its original domain or a different domain within the current forest. Specify the alternate container in the Restore To dialog box. For example, if the object was deleted from the Users container in the tech.windows-scripting.org domain, you could restore it to the Devs OU in the eng.windows-scripting.org domain.

About these ads

Posted in TUTORIALS | Tagged: , | Leave a Comment »

Active Directory Delegation

Posted by Alin D on March 21, 2011

Active directory

Active Directory Delegation

Active Directory delegation is an important task in the process of Active Directory management that requires careful planning and accurate implementation. Native Active Directory management tools are not able to cope with AD delegation tasks due to significant disadvantages. Third party solutions implement role-based access control model that proved its simplicity and effectiveness.

Active Directory management includes many tasks. Some of them are simple, though still very important. The necessity of rights delegation to non-administrative staff occurred when Active Directory administrators spent about 40 per cent of their time fulfilling those simple operations like reset of passwords, modification of users’ personal data, etc. Eventually it was decided that Active Directory delegation is vital to let the administrators solve more important challenges.

Active Directory delegation has a pitfall – security threat. When we deal with sensitive data, security is above all, that is why Active Directory delegation should be carefully planned and implemented with the possibility of constant revision of delegated rights. Native AD management tools do not cope with granular delegation of rights in Active Directory due to the following reasons: absence of central place for permissions storage, need of manual maintenance of multiple ACLs across Active Directory. Moreover, it is a huge problem to track what privileges were granted to users. Help of third party solutions is vital here.

Third party solutions proved their effectiveness for Active Directory delegation with the help of role-based access control approach that refers to delegation of responsibilities in a centralized manner. It is possible to create an administrative role, allocate a set of job functions to it and subsequently assign this administrative role to a user. Such approach helps control delegated permissions, assign and revoke those assigned even to large amount of users with the same job function.

Even though role-based access control helps significantly increase security by means of delegating limited rights to non-administrative staff, some actions still should be verified by responsible persons. This task is easily accomplished by means of approvals that are provided by third party Active Directory management software.

Active Directory delegation is a pressing problem for IT administrators as it involves possibility of security breaches and improper Active Directory audit. Third party AD management tools provide a vast range of features that help cope with the problem of Active Directory delegation, thus greatly reduce administrative misfortunes and headaches.

Experienced IT enthusiast.

 

Article from articlesbase.com

Posted in Windows 2008 | Tagged: , , , , | Leave a Comment »

Regarding Active Directory Management: Enhancing Network Construction And Functionality

Posted by Alin D on March 14, 2011

Active directory

Regarding Active Directory Management: Enhancing Network Construction And Functionality

Active Directory management software necessitates an understanding of the individual directories and various programs that are most efficient and effective. Active Directory management is such a critical aspect of your company’s network organization because it provides logical organization in a world that could quite easily turn into a wild ride of unorganized information overload insanity.

*** Briefly looking at the history of Active Directory management ***

Here are a few things to know about the emergence of Active Directory management:

• Active Directory was developed by Microsoft in 1996 and has been useful functionality in the IT world the past 15 years.

• The operating systems running on Windows use it most often, primarily to gather information about and monitor different domains.

• Over time, Active Directory has evolved from being able to view the flow of online data to also facilitating it.

Providing access to important and relevant objects within a network is one of the main attributes of Active Directory. Since it is built on a hierachical structure it is easy to understand. Domains, subjects, tress and forests can all be part of the Active Directory structure.

*** Presenting Spiceworks’ Active Directory management software ***

Spiceworks offers compatibility with Active Directory software with their “PeopleView” Functionality. IT managers are able to easily view visitor profiles with PeopleView. Benefits from this technology are seen both at the webmaster and network manager levels. It contains many great features for IT pros such as resetting user passwords, linking devices to specific users, and view all help tickets from a user at a glance.

How can I make Active Directory work for me?

When it comes to managing user profiles I recommend Spriceworks free Active Directory software! Download there free Active Directory management software, and in minutes, you’ll be able to lock users’ accounts and reset their passwords, link devices to specific users, and so much more.

As if that is not already awesome, Spiceworks.com also provides free support by phone and eMail plus a network of over 1,000,000 IT pros who are actively using their software. Get Spiceworks’ free Active Directory management.com now!

As if that is not already awesome, Spiceworks.com also provides free support by phone and eMail plus a network of over 1,000,000 IT pros who are actively using their software. Now that you know what is Active Directory you can secure your copy of Spiceworks’ free Active Directory management software now!

Article from articlesbase.com

Posted in Windows 2008 | Tagged: , , , , , , , , , , , , , , , , , | Leave a Comment »

Active Directory Federation Services

Posted by Alin D on January 24, 2011

One of the most exciting new features in Microsoft’s forthcoming R2 release of Windows Server 2003 is the Active Directory Federation Services (ADFS). ADFS is a single sign on technology that can be used to authenticate a user into multiple Web applications over the course of a single session. In this article, I will explain the key features of ADFS and how ADFS works.

What is ADFS?

ADFS extends Active Directory to the Internet. To understand what this means, think about how a normal Active Directory deployment works. When a user authenticates into an Active Directory environment, a domain controller checks the user’s credentials. Once users have been validated, they are free to access any resource on the Windows network (assuming they have permissions) without having to re-authenticate every time they access a different server.

ADFS applies this same concept to the Internet. We have all seen Web applications that access back-end data located on a SQL Server or on some other type of back-end resource. The challenge has always been providing secure authentication to those back-end resources. There are a few different authentication methods that traditionally have been used to provide this authentication. For example, users might authenticate into the application via a RADIUS (Remote Authentication Dial-In User Service) server or through a proprietary authentication mechanism that is a part of the application’s code.

Although these types of authentication mechanisms get the job done, they do have some drawbacks. One drawback has to do with account management. Account management isn’t usually a huge deal if the application will be accessed by your own employees, but what if your suppliers or your clients are going to be the ones accessing the application? All of a sudden you find yourself having to set up user accounts for employees of these other companies. Furthermore, there is the ongoing maintenance issue. When employees of these other companies quit and new employees are hired, you have to delete old accounts and create new ones. Passwords become an issue, too. You may find that once the application is deployed, your help desk stays a lot busier with password resets for people who do not even work for your company.

What can ADFS do for you?

What if you could shift the burden of account management to your clients, suppliers or whoever it is that uses your Web application? Imagine, if you will, a Web application that services employees from other companies, and you never have to create user accounts or reset passwords for those employees. As if this isn’t impressive enough, the people using the application never even have to log into the application. Sound too good to be true?

The main idea behind this technology is that you can create cross-forest trusts and extend that trust to Web applications. For example, suppose that you have a supplier who needs to access a Web application that you host. Rather than you having to setup and maintain a bunch of user accounts for your supplier, they could create a security group in their own Active Directory. That group would contain all of the users who need access to your Web application. Then, you simply grant application access to that group. It doesn’t matter that the group exists in a completely different Active Directory forest from the one that the Web application is hosted in. Now, when users on your supplier’s network attempt to access your Web application, they do not have to log into it. The application automatically authenticates the users based on their group membership.

Of course this is just an example of how you could set up a federated trust. R2 is not out yet and there is not presently a lot of information available on the ADFS configuration process. The actual configuration might be a little bit different than what I just described, but the general principle should be on track.

What does ADFS need?

Of course Active Directory Federation Services doesn’t happen by magic. To take advantage of it, you will have to have servers performing specific roles. One of the primary roles that must be filled is the federation server. The federation server hosts the federation service component of ADFS. The federation server’s job is to route requests that come in from external users. The federation server is also responsible for issuing tokens to users upon successful authentication.

Another role that is required in most situations is a federation proxy. Think about it for a minute. If an external network were to be able to establish a federation agreement with your network, it would mean that your federation server would have to be accessible over the Internet. Since Active Directory federation is so heavily dependant on the Active Directory, exposing the federation server directly to the Internet would be a huge security risk. So, instead, you would place a federation proxy at the perimeter of your network. This proxy would relay federation requests from the outside world to your federation server. And your federation server is not exposed directly to the outside world.

One other major component involved in ADFS is the ADFS Web agent. A Web application must have a mechanism for authenticating external users. This mechanism is the ADFS Web agent. The ADFS Web agent manages the security tokens and authentication cookies that are sent to the Web server.

As you can see, ADFS will greatly expand what can be done with Web applications. It will be interesting to see how ADFS is actually put to work in the real world once R2 is released.

Posted in Windows 2008 | Tagged: , , , , , | Leave a Comment »

Manage the Active Directory Domain Services Schema – Part 1

Posted by Alin D on January 11, 2011

Introduction

The Active Directory Domain Services (AD DS) schema contains formal definitions of every object class that can be created in an AD DS forest. The schema also contains formal definitions of every attribute that can exist in an AD DS object.

This article series describes the steps required to manage the schema.

In part one we will discuss about:

  • Install the Active Directory Schema Snap-In
  • Apply Active Directory Schema Administrative Permissions
  • View Schema Class and Attribute Definitions
  • Create Attributes
  • Deactivate Attributes

Install the Active Directory Schema Snap-In

To install the Active Directory Schema snap-in, perform the following steps:

1. Log on to a domain controller or a member computer that has Windows Server 2008 Remote Server Administration Tools (RSAT) installed.

2. Click Start, and click Command Prompt.

3. In the Command Prompt window, type the following command and press Enter: regsvr32 schmmgmt.dll

4. You will receive a notification that schmmgmt.dll was registered successfully, as shown in Figure 1. Click OK and close the Command Prompt window.

schmmgmt.dll was registered successfully
Figure 1. schmmgmt.dll was registered successfully

5. Click Start, click Run, type mmc /a, and click OK.

6. On the File menu, click Add/Remove Snap-In.

7. In the Add or Remove Snap-ins window, shown in Figure 2, select Active Directory Schema under Available Snap-ins, click Add, and then click OK. The Active Directory Schema snap-in is added to the MMC console, as shown in Figure 3.

Adding the Active Directory Schema snap-in to the MMC console.
Figure 2. Adding the Active Directory Schema snap-in to the MMC console.
Active Directory Schema snap-in
Figure 3. The Active Directory Schema snap-in

8. On the File menu, click Save As.

9. In the Save As window, type systemroot%System32schmmgmt.msc in the File name field, and click Save.

10. Close the console.

11. Right-click Start, and click Open All Users

12. Double-click Programs and double-click Administrative Tools.

13. On the File menu, click New; then click Shortcut.

14. In the Create Shortcut Wizard, shown in Figure 4, in the Type the Location of the Item box, type schmmgmt.msc; then click Next.

The Create Shortcut Wizard

15. On the Select a Title for the Program page, in the Type a name for this shortcut, type Active Directory Schema; then click Finish.

16. To verify that the Active Directory Schema shortcut was created successfully, click Start, click Administrative Tools, and verify that Active Directory Schema is listed.

View Schema Class and Attribute Definitions

To view schema class and attribute definitions, perform the following steps:
1. Log on to a domain controller or a member computer that has Windows Server 2008 RSAT installed.
2. Click Start, click Administrative Tools, and click Active Directory Schema.
3. In the console tree, expand Active Directory Schema.
4. To view schema class definitions, click the Classes node in the console tree, as shown Below

image

5. To view schema attribute definitions, click the Attributes node in the console tree, as shown in Figure below

image

Create Attributes

To create an attribute, perform the following steps:
1. Log on to a domain controller or a member computer that has Windows Server 2008 RSAT installed.
2. Click Start, click Administrative Tools, and click Active Directory Schema.
3. In the console tree, expand Active Directory Schema and then click Attributes.
4. On the Action menu, click Create Attribute.
5. On the Schema Object Creation warning, shown in the next picture, click Continue.

image

On the Create New Attribute window, shown in Figure below do the following:

Type a common name in the Common Name field.
Type an LDAP display name in the LDAP Display Name field.
Type the OID in the Unique X500 Object ID field.
Type a description in the Description field, if required.
Select the attribute syntax in the Syntax field.
Type a minimum acceptable value in the Minimum field, if required.
Type a maximum acceptable value in the Maximum field, if required.
Select Multi-Valued if the attributed is a multivalued attribute.

image

7. Click OK to create the new attribute.

Deactivate Attributes

To deactivate an attribute, perform the following steps:
1. Log on to a domain controller or a member computer that has Windows Server 2008 RSAT installed.
2. Click Start, click Administrative Tools, and click Active Directory Schema.
3. In the console tree, expand Active Directory Schema and then click Attributes.
4. In the details pane, right-click the attribute you want to deactivate and click Properties.
5. On the attribute’s properties page, shown in next Figure, deselect the check box next to Attribute is active.

image

6. On the warning box for making the schema object defunct, shown in next Figure, click Yes.
7. Click OK to save the changes.

image

Posted in Windows 2008 | Tagged: , , , | Leave a Comment »

Change the Routing Status of a Name Suffix

Posted by Alin D on January 11, 2011

Introduction

Name suffix routing allows you to control authentication requests thattake place between forests that are joined by a forest trust. By using the ActiveDirectory Domains and Trusts console, you can change the routing status of aname suffix.

How To

To complete this task, you must use an AD DS account that has membership in the following AD DS group:
Domain Admins

To change the routing status of a name suffix, perform the following steps:

1. Log on to a domain controller or a member computer that has Windows Server 2008 Remote Server Administration Tools installed.

2. Click Start, click Administrative Tools, and then click Active Directory Domains and Trusts.

3. In the console tree, right-click the domain node for the forest root domain; then click Properties.

4. Click the Trusts tab.

5. Select an outgoing or incoming trust and click Properties. The properties page for forest trust is shown in Figure 1.

The Trust Properties General tab

Figure 1. The Trust Properties General tab

6. On the Trust Properties page, click the Name Suffix Routing tab, as shown in Figure 2.

The Trust Properties General tab

Figure 2. The Trust Properties General tab

7. Click the name suffix you want to modify, and select Edit.

8. On the Edit Name Suffix page, click the suffix you want to modify and click Enable or Disable.

Posted in TUTORIALS | Tagged: , , , , , | Leave a Comment »

How to transfer some or all of the FSMO Roles from one DC to another

Posted by Alin D on December 20, 2010

Windows 2008/2003 Active Directory domains utilize a Single Operation Master method called FSMO (Flexible Single Master Operation), as described in Understanding FSMO Roles in Active Directory

In most cases an administrator can keep the FSMO role holders (all 5 of them) in the same spot (or really, on the same DC) as has been configured by the Active Directory installation process. But, there are scenarios where an administrator would want to go one or more of the FSMO roles from the default holder DC to a different DC.
Moving the FSMO roles while both the original FSMO role holder and the future FSMO role holder are online and operational is called Transferring, and is described in this article.
The transfer of an FSMO role is the suggested form of moving a FSMO role between domain controllers and can be initiated by the administrator or by demoting a domain controller. But, the transfer process is not initiated automatically by the operating system, for example a server in a shut-down state. FSMO roles are not automatically relocated during the shutdown process – this must be considered when shutting down a domain controller that has an FSMO role for maintenance, for example.
In a graceful transfer of an FSMO role between two domain controllers, a synchronization of the data that is maintained by the FSMO role owner to the server receiving the FSMO role is performed prior to transferring the role to ensure that any changes have been recorded before the role change.
But, when the original FSMO role holder went offline or became non operational for a long period of time, the administrator might consider moving the FSMO role from the original, non-operational holder, to a different DC. The process of moving the FSMO role from a non-operational role holder to a different DC is called Seizing, and is described in the Seizing FSMO Roles article.
You can transfer FSMO roles by using the Ntdsutil.exe command-line utility or by using an MMC snap-in tool. Depending on the FSMO role that you want to transfer, you can use one of the following three MMC snap-in tools:

Active Directory Schema snap-in
Active Directory Domains and Trusts snap-in
Active Directory Users and Computers snap-in
To transfer the FSMO role the administrator must be a member of the following group:

FSMO Role Administrator must be a member of
Schema Schema Admins
Domain Naming Enterprise Admins
RID Domain Admins
PDC Emulator
Infrastructure
Transferring the RID Master, PDC Emulator, and Infrastructure Masters via GUI
To Transfer the Domain-Specific RID Master, PDC Emulator, and Infrastructure Master FSMO Roles:

Open the Active Directory Users and Computers snap-in from the Administrative Tools folder.
If you are NOT logged onto the target domain controller, in the snap-in, right-click the icon next to Active Directory Users and Computers and press Connect to Domain Controller.
Select the domain controller that will be the new role holder, the target, and press OK.
Right-click the Active Directory Users and Computers icon again and press Operation Masters.
Select the appropriate tab for the role you wish to transfer and press the Change button.
Press OK to confirm the change.
Press OK all the way out.
Transferring the Domain Naming Master via GUI
To Transfer the Domain Naming Master Role:

Open the Active Directory Domains and Trusts snap-in from the Administrative Tools folder.
If you are NOT logged onto the target domain controller, in the snap-in, right-click the icon next to Active Directory Domains and Trusts and press Connect to Domain Controller.
Select the domain controller that will be the new role holder and press OK.
Right-click the Active Directory Domains and Trusts icon again and press Operation Masters.
Press the Change button.
Press OK to confirm the change.
Press OK all the way out.
Transferring the Schema Master via GUI
To Transfer the Schema Master Role:

Register the Schmmgmt.dll library by pressing Start > RUN and typing:
regsvr32 schmmgmt.dll
Press OK. You should receive a success confirmation.
From the Run command open an MMC Console by typing MMC.
On the Console menu, press Add/Remove Snap-in.
Press Add. Select Active Directory Schema.
Press Add and press Close. Press OK.
If you are NOT logged onto the target domain controller, in the snap-in, right-click the Active Directory Schema icon in the Console Root and press Change Domain Controller.
Press Specify …. and type the name of the new role holder. Press OK.
Right-click right-click the Active Directory Schema icon again and press Operation Masters.
Press the Change button.
Press OK all the way out.
Transferring the FSMO Roles via Ntdsutil
To transfer the FSMO roles from the Ntdsutil command:
Caution: Using the Ntdsutil utility incorrectly may result in partial or complete loss of Active Directory functionality.

On any domain controller, click Start, click Run, type Ntdsutil in the Open box, and then click OK.
Microsoft Windows [Version 5.2.3790] (C) Copyright 1985-2003 Microsoft Corp. C:WINDOWS>ntdsutil ntdsutil:
Type roles, and then press ENTER.
ntdsutil: roles fsmo maintenance:
Note: To see a list of available commands at any of the prompts in the Ntdsutil tool, type ?, and then press ENTER.

Type connections, and then press ENTER.
fsmo maintenance: connections server connections:
Type connect to server , where is the name of the server you want to use, and then press ENTER.
server connections: connect to server server100 Binding to server100 … Connected to server100 using credentials of locally logged on user. server connections:
At the server connections: prompt, type q, and then press ENTER again.
server connections: q fsmo maintenance:
Type transfer . where is the role you want to transfer.
For example, to transfer the RID Master role, you would type transfer rid master:
Options are:

Transfer domain naming master Transfer infrastructure master Transfer PDC Transfer RID master Transfer schema master
You will receive a warning window asking if you want to perform the transfer. Click on Yes.
After you transfer the roles, type q and press ENTER until you quit Ntdsutil.exe.
Restart the server and make sure you update your backup.

Posted in Windows 2008 | Tagged: , , , , | Leave a Comment »

Active Directory Lightweight Directory Service

Posted by Alin D on November 26, 2010

Introduction

The Lightweight Directory Service is useful for situations in which applications need access to a directory service, but you do not want to risk compromising your Active Directory database. In this article, you will be introduced to the Lightweight Directory Services, its uses, and capabilities.

When Microsoft introduced the Active Directory with Windows 2000, it didn’t take long before people began to realize that the Active Directory was really little more than a centralized database, and that the Active Directory could be used for purposes for which it was never intended.

For a while, it seemed as though almost every software vendor was designing their wares to be Active Directory integrated. Many such applications stored their configuration information in the Active Directory, and some even whet so far as to actually treat the Active Directory as an alternative to a SQL database and store actual application data in the Active Directory database.

Today, most of the third party software publishers seem to take less invasive approach to the way that they interface with the Active Directory. Many applications read Active Directory data, but not nearly as many applications seem to store data within the Active Directory as did a few years back. Although I can only speculate on the reasons for this, I suspect that it has something to do with the fact that the Active Directory has become a critical component of the network infrastructure, and many administrators are reluctant to perform unnecessary schema extensions (which are almost always necessary to support applications that store data within the Active Directory).

Even though software publishers may not use the Active Directory to quite the extent that they once did, I think that it is safe to say that the Active Directory can be very useful for supporting various applications. To show you what I mean, consider the fact that Microsoft still designs many of their server applications with a high degree of Active Directory integration. Exchange Server 2007 and Exchange Server 2010 for example, are designed in such a way that all of the server configuration information is stored in the Active Directory, rather than being stored locally on the server. The advantage to doing so is that it makes it possible to regenerate a failed server on the fly.

Suppose for instance that you had a catastrophic hard disk failure on an Exchange 2010 server that was hosting the Hub Transport Server Role. Because of the way that Exchange stores its configuration information in the Active Directory, you wouldn’t even have to restore a backup in order to fix the problem. Instead, you would start out by resetting the Computer account for the failed server within the Active Directory. You would then install Windows and any applicable service packs onto a new server. Next, you would assign that server the same computer name as your failed server had used, and join the new server to the Active Directory. Because you reset the Active Directory computer account, the new server is able to use it.

From there, fixing the problem is as simple as running Exchange Server’s Setup program with a special switch. Setup installs the necessary binaries, and then configures the server according to the configuration information found in the Active Directory. The new server can be up and running in less than an hour, and without ever restoring a backup.

My point is that the Active Directory can be very useful for application support, but that many software publishers are reluctant to use it to the extent that Microsoft does, because of the stigma that’s attached to making Active Directory schema extensions.

Another reason why you don’t see more software publishers storing a lot of data in the Active Directory has to do with Active Directory replication. Generally speaking, any data that is stored in the Active Directory must be replicated to all of the domain controllers in the domain (possibly even all of the domain controllers in the forest). As such, if an application were to store a large volume of data in the Active Directory, that data could impact the speed of the normal replication process – especially if that data changes frequently.

In spite of these challenges, there is a way to reap the benefits of Active Directory integration, without impacting your Active Directory database in the process. Windows Server 2008 and Windows Server 2008 R2 include a service called the Active Directory Lightweight Directory Service, or AD LDS.  A similar service also exists in Windows Server 2003, but goes by the name Active Directory Application Mode (or ADAM).

In case you are not familiar with AD LDS, it provides you with an environment that is very similar to, but completely separate from, the Active Directory. AD LDS is a standalone service that has no dependency on the Active Directory Directory Service. In fact, it is common to deploy AD LDS in environments in which no Active Directory domains exist.

A perfect example of such a situation is Microsoft Exchange Server. Earlier I said that Exchange Server 2007 and 2010 are both designed to store all of their configuration information in the Active Directory database. There is one big exception to this however.

Exchange Server defines a series of roles that dictate how an Exchange Server is configured, and what tasks the server performs. All but one of the server roles are designed to store the server configuration in the Active Directory.

The server role that does not use the Active Directory is known as the Edge Transport Server Role. The Edge Transport Server is designed to reside at the network perimeter and keep the other Exchange Servers from being directly exposed to the Internet.

Because the Edge Transport Server is exposed to various Internet based threats, making it a member of an Active Directory domain could be a potential security risk. If someone were able to compromise the edge transport server, they may be able to use it to gain information about the Active Directory.

To keep this from happening, the Edge Transport Server cannot be a domain member, and it cannot host any other Exchange Server roles. Even so, the Edge Transport Server does require access to a minimal amount of Active Directory information so that it can do its job. Rather than provide the server with direct access to the Active Directory, Microsoft has designed the Edge Transport Server role to use AD LDS.

One of the backend Exchange Servers reads the required information from the Active Directory, and sends the information to the AD LDS partition on the Edge Transport Server. That way, the Edge Transport Server has access to the information that it needs, without being able to access the Active Directory. Incidentally, the Edge Transport Server also stores its own configuration information in the AD LDS partition, just as other Exchange Server roles store configuration information in the Active Directory.

Now that I have talked about what the AD LDS is and what it is used for, I want to turn my attention to using this service in your own organization. In Part 2, I will begin discussing the hardware and the software requirements for using AD LDS.

The Planning Process

Planning for the deployment of AD LDS can actually be something of a trial and error experience because Microsoft really doesn’t give you a lot to go on. If you look at Microsoft’s AD LDS Overview on TechNet, you can see that the Hardware and Software Considerations section consists of a block of text telling you to “Use performance counters, testing in the lab, data from existing hardware in a production environment, and pilot roll outs to determine the capacity needs of your server.”

So what is Microsoft really saying here? Well, I think that the statement in the paragraph above can best be summarized like this:

In order to deploy AD LDS, one needs only to have a server that is capable of running Windows Server 2008. However, depending on how AD LDS is being used the server may have to support a considerable workload. It is therefore necessary to take measures to ensure that your server hardware is up to the job.

If this statement is true, then the most logical approach to AD LDS planning is to take a look at the types of resources AD LDS consumes, and base any capacity planning efforts on those types of resource consumption.

Being that Microsoft doesn’t seem to provide a lot of clear guidelines for AD LDS capacity planning, I tend to think that one of the best approaches is to treat the capacity planning process similarly to the capacity planning process that you would use for domain controllers. After all, an AD LDS server is very similar to a domain controller. Both AD LDS servers and domain controllers host nearly identical directory services. Of course there are differences that you have to keep in mind. Active Directory capacity planning usually takes the number of users into account, while AD LDS capacity planning is usually more about anticipating the number of LDAP requests that will be made against the server. However, both Active Directory and AD LDS capacity planning often require you to plan for things like topology and replication.

The Differences between Domain Controllers and AD LDS Servers

Of course even though domain controllers and AD LDS servers are very similar at the architectural level, the simple fact that domain controllers are used to authenticate logins and implement Windows security policies means that there are some aspects of domain controller planning that simply will not apply to the planning process for AD LDS.

One such difference is that AD LDS does not use the concept of forests like the Windows Active Directory does. In an Active Directory environment, a forest is a collection of domains. Every forest is completely independent, although forests can be joined together through the use of federated trusts.

AD LDS does not use the concept of forests and domains like Windows domain controllers do. Instead, the primary structural element used by AD LDS is that of a service instance (which Microsoft often refers to as an instance).  An instance refers to a single AD LDS partition. Each instance has its own individual service name, directory data store, and service description.

As I’m sure you probably already know, a Windows domain controller can only service a single domain. In contrast, a single server running AD LDS can host multiple instances. This means that a single AD LDS server can contain multiple directories.

Of course this raises an interesting question. In an Active Directory environment, clients communicate with domain controllers using the Lightweight Directory Access Protocol (LDAP). Like most other protocols, LDAP is designed to use specific port numbers. For example, LDAP typically uses port 389 for directory queries. If LDAP communications need to be encrypted then port 636 is uses instead. Domain controllers that are functioning as global catalog servers use ports 3268 and 3269 for global catalog related functions. With all of this in mind, you may be wondering which ports AD LDS uses.

Well, AD LDS does not have to worry about performing any global catalog functions, so we can rule out the use of ports 3268 and 3269 right off the bat. AD LDS does however make use of ports 389 and 636 in exactly the same way that a domain controller would.

So what happens if a server is hosting multiple AD LDS instances? Typically, the first instance to be created would be assigned to use ports 389 and 636. When the second instance is created, Windows sees that these ports are in use, and begins scanning for unused ports beginning with port 50,000. Assuming that port 50,000 is available it will be used for standard LDAP communications with the second AD LDS instance. Port 50,001 will be used for SSL encrypted LDAP communications with the second AD LDS instance.

If you were to create a third AD LDS instance on the server, then Windows would see that ports 389 and 636 were in use, so it would begin looking for unused ports starting with 50,000. Since ports 50,000 and 50,001 have already been assigned, the third LDAP partition will be assigned to ports 50,002 and 50,003.

DNS Requirements

Another difference between the Active Directory and AD LDS is that the Active Directory is totally dependent on DNS servers. Without DNS, the Active Directory cannot function. AD LDS on the other hand does not require DNS.

In some ways this makes sense. The Active Directory uses DNS as a mechanism for maintaining the domain hierarchy. There is no domain hierarchy associated with AD LDS, so DNS is unnecessary.

Installing the Active Directory Lightweight Directory Service

Installing AD LDS is actually a very simple process. To do so, open the Server Manager, and then click on the Add Roles link. When you do, Windows will launch the Add Roles Wizard. Click Next to bypass the wizard’s welcome screen and you will be taken to a screen that displays all of the available server roles.

Select the Active Directory Lightweight Directory Services check box, as shown in Figure A.


Figure A: Active Directory Lightweight Directory Service.

Click Next, and you will see an introductory screen that explains what the AD LDS is and what it does. Click Next and Windows will display a confirmation message indicating that the AD LDS server role is about to be installed. Click theInstall button to begin the installation process.

The entire installation process usually only takes about 30 seconds to complete. After the server role finishes installing, click the Close button to complete the installation process. Unlike some of the Windows 2008 server roles, installing the AD LDS role does not require you to reboot the server.

Conclusion

In this article, I have explained some of the differences between the Active Directory and AD LDS. In Part 3 of this series, I will begin showing you the basics of working with AD LDS.

Posted in Windows 2008 | Tagged: , , , , , , , , , , , , , , , , , , , , , , , | Leave a Comment »

 
Follow

Get every new post delivered to your Inbox.

Join 479 other followers

%d bloggers like this: