Prepare Active Directory for site publishing

When you extend the Active Directory schema for System Center Configuration Manager, you introduce new structures to Active Directory that are used by Configuration Manager sites to publish key information in a secure location where clients can easily access it.

It's a good idea to use Configuration Manager with an extended Active Directory schema when you manage on-premises clients. An extended schema can simplify the process of deploying and setting up clients. An extended schema also lets clients efficiently locate resources like content servers and additional services that the different Configuration Manager site system roles provide.

• If you're not familiar with what extended schema provides for a Configuration Manager deployment, you can read about Schema extensions for System Center Configuration Manager to help you make this decision.
• When you don't use an extended schema, you can set up other methods like DNS and WINS to locate services and site system servers. These methods of service location require additional configurations and are not the preferred method for service location by clients. To learn more, read Understand how clients find site resources and services for System Center Configuration Manager,
• If your Active Directory schema was extended for Configuration Manager 2007 or System Center 2012 Configuration Manager, then you don't need to do more. The schema extensions are unchanged and will already be in place.

Extending the schema is a one-time action for any forest. To extend, and then use the extended Active Directory schema, follow these steps:

Step 1. Extend the schema

To extend the schema for Configuration Manager:

• Use an account that is a member of the Schema Admins security group.
• Be signed in to the schema master domain controller.
• Run the Extadsch.exe tool, or use the LDIFDE command-line utility with the ConfigMgr_ad_schema.ldf file. Both the tool and file are in the SMSSETUP\BIN\X64 folder on the Configuration Manager installation media.

Option A: Use Extadsch.exe

1. Run extadsch.exe to add the new classes and attributes to the Active Directory schema.
   Tip

   Run this tool from a command line to view feedback while it runs.
2. Verify that the schema extension was successful by reviewing extadsch.log in the root of the system drive.

Option B: Use the LDIF file

1. Edit the ConfigMgr_ad_schema.ldf file to define the Active Directory root domain that you want to extend:
   • Replace all instances of the text, DC=x, in the file with the full name of the domain to extend.
   • For example, if the full name of the domain to extend is named widgets.microsoft.com, change all instances of DC=x in the file to DC=widgets, DC=microsoft, DC=com.
2. Use the LDIFDE command-line utility to import the contents of the ConfigMgr_ad_schema.ldf file to Active Directory Domain Services:
   • For example, the following command line imports the schema extensions to Active Directory Domain Services, turns on verbose logging, and creates a log file during the import process: ldifde -i -f ConfigMgr_ad_schema.ldf -v -j .
3. To verify that the schema extension was successful, review a log file created by the command line used in the previous step.

Step 2. Create the System Management container and grant sites permissions to the container

After you extend the schema, you must create a container named System Management in Active Directory Domain Services (AD DS):

• You create this container one time in each domain that has a primary or secondary site that will publish data to Active Directory.
• For each container, you grant permissions to the computer account of each primary and secondary site server that will publish data to that domain. Each account needs Full Controlto the container with the advanced permission, Apply onto, equal to This object and all descendant objects.

To add the container

1. Use an account that has the Create All Child Objects permission on the System container in Active Directory Domain Services.
2. Run ADSI Edit (adsiedit.msc), and connect to the site server's domain.
3. Create the container:
   • Expand Domain , expand , right-click CN=System, choose New, and then choose Object.
   • In the Create Object dialog box, choose Container, and then choose Next.
   • In the Value box, enter System Management, and then choose Next.
4. Assign permissions:
   Note

   If you prefer, you can use other tools like the Active Directory Users and Computers administrative tool (dsa.msc) to add permissions to the container.
   • Right-click CN=System Management, and then choose Properties.
   • Choose the Security tab, choose Add, and then add the site server computer account with the Full Control permission.
   • Choose Advanced, choose the site server's computer account, and then choose Edit.
   • In the Apply onto list, choose This object and all descendant objects.
5. Choose OK to close the console and save the configuration.

Step 3. Set up sites to publish to Active Directory Domain Services

After the container is set up, permissions are granted, and you have installed a Configuration Manager primary site, you can set up that site to publish data to Active Directory.

Create a forest trust

To create a forest trust

1. Open Active Directory Domains and Trusts.
2. In the console tree, right-click the domain node for the forest root domain, and then click Properties.
3. On the Trust tab, click New Trust, and then click Next.
4. On the Trust Name page, type the DNS name (or NetBIOS name) of another forest, and then click Next.
5. On the Trust Type page, click Forest trust, and then click Next.
6. On the Direction of Trust page, do one of the following:
   • To create a two-way, forest trust, click Two-way.
     Users in this forest and users in the specified forest can access resources in either forest.
   • To create a one-way, incoming forest trust, click One-way:incoming.
     Users in the specified forest will not be able to access any resources in this forest.
   • To create a one-way, outgoing forest trust, click One-way:outgoing.
     Users in this forest will not be able to access any resources in the specified forest.
7. Continue to follow the wizard.

Important

• To successfully create a forest trust, your environment will need to be set up properly. For more information, see the checklist for creating a forest trust in Related Topics.

Notes

• To perform this procedure, you must be a member of the Domain Admins group (in the forest root domain) or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure. For more information, see Default local groups, Default groups, and Using Run as.
• If you are a member of the Incoming Forest Trust Builders group, you can create one-way, incoming forest trusts to this forest.
• To open Active Directory Domains and Trusts, click Start, click Control Panel, double-click Administrative Tools, and then double-click Active Directory Domains and Trusts.
• On a domain controller running Windows Server 2003, the forest root domain is the first domain listed in the console tree in Active Directory Domains and Trusts. This configuration is not provided on domain controllers running Windows 2000.
• If you have the appropriate administrative credentials for each forest, you can create both sides of a forest trust at the same time by clicking Both this domain and the specified domain on the Sides of Trust page. For more information, see Related Topics.
• If you want users from the specified forest to have access to all computers in the local forest, on the Outgoing Trust Properties page, click Forest-wide authentication. This option is preferred when both forests belong to the same organization.
• If you want to selectively limit authentication to particular users and groups from the specified forest, on the Outgoing Trust Properties page, click Selective authentication. This option is preferred if the specified forest belongs to a separate organization.
• In addition to creating new trusts, you can modify existing trusts by clicking the Trust tab.
• The command-line tool Dsmod.exe does not support the addition of security principals in one forest to groups that are located in another forest when both forests are joined by a forest trust. You can use the Active Directory Users & Computers snap-in to add security principals across a forest trust.

How To Edit the Active Directory Using ADSI Edit

I think that it's probably safe to say that most Windows admins are familiar with the Active Directory. The Active Directory was first introduced with Windows 2000 Server, and will be turning 20 years old in a couple of years. Sure, the Active Directory has evolved a bit along the way, but it still adheres to the same basic structure that it did when it was first introduced so long ago.

Many of the Active Directory-related tools that we have today can also trace their roots back to much earlier versions of Windows. For example, the Active Directory Users and Computers tool that exists today in Windows Server 2016 really hasn't changed very much over the years.

The point is that Active Directory is a mature technology, and most Windows Server admins probably know how to use the various Active Directory tools to perform tasks such as creating user accounts, sites, and OUs. Even so, the usual Active Directory tools can be inadequate in some situations. These tools are designed to be safe, and to protect inexperienced administrators from making potentially catastrophic mistakes. Sometimes however, the same safety mechanisms that exist to protect us can also get in the way.  This is where the ADSI Edit tool comes into play.

Before I show you what the ADSI Edit tool looks like, and how to use it, I want to compare it to another tool that is built into Windows -- the Registry Editor. As I'm sure you know, the vast majority of Windows' configuration settings are stored in the Windows registry. In fact, many of the GUI based management utilities are really nothing more than registry front ends. When you use the Group Policy Editor to make a change to a policy for example, the Group Policy Editor is actually editing the registry behind the scenes on your behalf.

GUI-based tools such as the Group Policy Editor exist for two purposes. First, they make an administrator's life easier by exposing related settings in some sort of logical way. Imagine how much more difficult it would be to implement a complex collection of group policy settings if you had to track down each policy setting through Registry Editor.

The other thing that GUI based tools such as the Group Policy Editor do for us, is that they make basic administrative tasks much safer than they would be if we had to do everything through the Registry Editor. Editing the registry can be dangerous. If you make a mistake while editing the registry, you can destroy Windows. The various Windows administrative tools are designed to make registry edits much safer by acting as an isolation boundary between the administrator and potentially dangerous registry settings.

These are the same two things that the various Active Directory tools are designed to do. Such tools present the Active Directory elements in a more simplified and logical way, while also making the process of editing the Active Directory far less dangerous than it might otherwise be.

The problem with the built-in Windows administrative tools however, is that they can't help in every situation. Sometimes an administrator must directly edit the registry in order to fix a problem. That's where the Registry Editor comes into play. Similarly, there are some Active Directory problems that simply cannot be fixed using the usual tools, and that's where ADSI Edit comes into play. For example, I have used ADSI Edit to remove Active Directory remnants that were left behind by a failed Exchange Server installation. Like the Registry Editor however, ADSI Edit bypasses all of the usual safeguards, and you can do catastrophic damage by using it incorrectly, so it is a good idea to back up your Active Directory prior to using this tool.

The easiest way to access ADSI Edit is by choosing the ADSI Edit command from the Server Manager's Tools menu. Upon doing so, you will be presented with a condole screen that looks like the one shown in Figure 1.

Figure 1. This is what the ADSI Edit console looks like.

The first step in putting this tool to work is to connect it to your Active Directory. To do so, choose the Connect To command from the Action menu. This will bring up the Connection Settings dialog box. You must select the naming context that you want to connect to. In most cases the defaults work just fine, as shown in Figure 2.

Figure 2. In most cases you can get away with using the defaults.

Once you connect to the Active Directory, the console will look like what you see in Figure 3. Like the Registry Editor, ADSI Edit uses a hierarchical, tree view. The difference however, is that the option to expand the Default Naming Context and other layers of the hierarchy does not appear until the node is clicked on.

Figure 3. This is what it looks like after you connect to the Active Directory.

As you navigate the Active Directory, things should begin to look a lot more familiar. As you can see in Figure 4, ADSI Edit gives you the ability to move, delete, rename, or otherwise modify objects that you wouldn't ordinarily be able to.

Figure 4. This is what it looks like to use ADSI Edit.

PowerShell: Get-ADUser to see password last set and expiry information and more

Get-ADUser to see password last set and expiry information and more

Open Active Directory Module for Windows PowerShell To Run as administrator
help Get-ADUser









Get-ADUser -identity yaniv -properties *









get-aduser -filter * -properties passwordlastset, passwordneverexpires |ft Name, passwordlastset, Passwordneverexpires









get-aduser -filter * -properties passwordlastset, passwordneverexpires | sort name | ft Name, passwordlastset, Passwordneverexpires









Get-ADUser -filter * -properties passwordlastset, passwordneverexpires | sort-object name | select-object Name, passwordlastset, passwordneverexpires | Export-csv -path c:\yaniv.csv