Editing users of other domains – with PowerShell

An experienced AD administrator uses the PowerShell cmdLets „Get-ADUser“ and „Set-ADUser“ for many automated processes in the domain. However, what is the procedure if the administrator needs to edit users in another domain in the forest? This article will show you an easy solution.

Editing users of other domains – Three questions

How can I simply edit users in another domain? The common answer to this question would be: “Simply change to the other domain and run your script there!” Even though this will work it is a roundabout way and cumbersome solution for automated processes. You would have to execute the script in every domain of your forest. But of course there is an easier way too.

To implement a PS script for other domains you need to answer three questions:

1. Where do I find the user?
2. How do I know from which domain the user originates?
3. How do I save changes in the respective domain?

The first question is easy to answer. That is, if you have ever used more than one domain in your forest:

The Global Catalog (GC).

The Global Catalog

The GC is a partition of a domain controller (DC) which saves all objects of all domains in the forest. Therefore, you have to activate the GC on the domain controller. Once you activated it, the DC will become the designated Global Catalog Server.

Theoretically it doesn’t matter which domain controller you address on your domain. However, it is essential that the domain controller is also a GC-Server. The Global Catalog is the same  everywhere.

In practice, it depends on the replication speed which again depends on the size and number of objects, the network speed etc.

To address the Global Catalog of a DC or a forest with PowerShell is relatively easy.

You need two pieces of information:

• Name of the server
• Port of the GC connection

In principle, „Get-ADUser“ runs a LDAP query in the background. Typically it is Port 389 for queries against the domain. For queries against the Global Catalog it is Port 3268 (or 636 and 3269, respectively, for SSL-connections). In the “Get-ADUser” cmdLet you need to include the port in the server properties along with the server name.

Caution with objects from Global Catalog

As a result, the user object looks almost like you retrieved it directly from the domain itself. However, „almost“ is quite crucial here. The object does not contain all the features of the source domain. Active Directory does not replicate all user information in the GC but rather contains a partial replica of selected, pre-set properties.

Example: Accessing a domain

You run a query directly on the domain to find a user’s department by including the ‘department’ attribute.

Example: Accessing the Global Catalog

You run a query to find the user’s department. Interestingly, the attribute ‘department’ does not return any value.

The reason is: AD does not replicate the ‘department’ attribute in the GC. This explains the blank space in the second query. The script will not show any errors because the attribute generally does exist – however, without a value. If there are certain attributes which you categorically need and which are not included as default attributes in your GC, you can replicate these in the GC.

Finally you have found a user object. You can edit the various attributes in PowerShell the way you are used to.

Saving changes in the GC is not possible

By now you might like to save your changes. It is worth mentioning that the GC is ‘Read Only’ – for good reasons. If it was possible to edit AD objects in the GC directly, many replication errors and synchronization problems would be inevitable. Therefore, to edit users you have to go back to the domain from which the user originates. First, you have to find out which domain this is. Unfortunately this information is not available in the user properties.

Finding the correct domain

For sure there are many hints and tricks on how to proceed. There is a simple, almost rudimental way which is easy to apply. You will always be able to find the domain implicitly in the user object. There is one attribute which every user has and which clearly identifies the user on the domain: DistinguishedName. Everything that is included in the „DC=“-part belongs to the FQDN (Fully-Qualified Domain Name) of the domain the user originates from. The task is to find out where the domain part in DistinguishedName begins and to format it according to the FQDN.

Triggering and processing „DC=“ substring

For this purpose you can simply manipulate the string. To start off with, you find the first “DC=” in the string, then you separate the substring which follows behind. As a third step, you delete all commas and replace the remaining “DC=” with a full stop. Finally you have the FQDN you were looking for.

In PowerShell it looks like this:

Here are the intermediate steps:

Writing the changes in the correct domain

Now you already know where the user belongs to. So you can answer the third and last question easily: Save the changes by including the FDQN in the server properties of the PowerShell cmdLet „Set-ADUser“:

With this simple script you can edit users who are located on any domain of your forest, from your domain. You do not need to know in advance from which domain the user originates.

Editing users of other domains – The complete script

In summary, here is the whole script put together for you to copy:

This functionality is frequently used in the FirstWare IDM-Portal.

Thanks to the PowerShell provider it is possible to connect scripts to different processes. If you create or edit a user on the web interface of the IDM-Portal, you can run such a script afterwards. It automatically creates attributes depending on the changes made in the user account. For instance, you create a new user and fill in first name (givenName) and last name (sn). After saving the changes these parameters are automatically transferred to a PowerShell script. Subsequently, the script can create attributes like an e-mail address based on these parameters. Since FirstWare IDM-Portal is designed to handle multiple domains the PowerShell scripts can also edit users from other domains.