Active Directory: Several companies share an Active Directory

I have now received a number of inquiries asking how several companies can share an Active Directory. The last inquiry was about a company that had bought out another company. The companies should now share the infrastructure. In the standard setting of an Active Directory, however, all users have read rights, this was no longer desired, the companies should only see their own users, but still be managed in the same AD.

I have recreated the environment from the request to make it a little clearer. There is an Active Directory with the name "cloud.frankysweb.de" (was actually intended to play a bit with Azure...). There are separate organizational units for the acquired companies (CompanyA and CompanyB) in which the respective objects of the companies are managed:

The aim is that users of companyA can only see and, if necessary, manage their objects, but not the objects of companyB. The same applies to companyB.

As you can see in the screenshot, I have created an OU "Companies", which contains an OU for CompanyA and CompanyB. I have also created a "Shadow Groups" OU. But more on that later.

Note: The implementation is not entirely trivial and should therefore definitely be tested beforehand. This article does not go into all the details that need to be considered. At this point, I would just like to point out a possible way of implementation. This is not about setting up a hosting environment.

Preparation

For the method described here to work, you must first get rid of a "legacy issue". In the Active Directory there is a group called "Pre-Windows 2000 compatible access" in the "Builtin" OU, this group contains "Authenticated users" as members. As the name suggests, pre-Windows 2000 was the NT4 era (click, reboot, click, reboot). To make the implementation a little easier, I have removed "Authenticated Users" from the group, so the group is empty:

The actual Active Directory feature, which makes it possible to restrict the read rights for users, is called "dSHeuristics". This feature must first be activated. The activated dSHeuristics function causes the "List object" and "List content" rights to be evaluated on each OU. Using dSHeuristics, it is therefore possible to hide certain OUs and objects for users if they have no rights on the corresponding OU.

Via ADSIEdit, dSHeuristics can be activated in the Active Directory configuration partition (Deactivated = Not defined, Activated = 001):

In the Active Directory, I have also created an OU with the name "Shadow Groups". In the OU there is one group for companyA and one group for companyB. The group SG-CompanyA contains all user accounts of CompanyA. SG-CompanyB contains all user accounts of CompanyB. These groups are later used for the authorizations of the OUs. Here it must be ensured that the groups always contain all user accounts of the respective companies. However, this is easy to do with a small script.

This already fulfills the requirements. This was the easy part.

Note: All changes to the Active Directory should be documented precisely, and this will become all the more important as the process continues.

For the existing OUs

To ensure that users only see their own OU, the permissions of the OUs must be changed. For this to be possible in the Active Directory Computers and Users console, the "Advanced features" must be displayed:

Inheritance is now interrupted on the "Companies" OU:

The inherited authorizations are converted into explicit authorizations and can then be changed:

The authorization for the "Authenticated users" group can now be changed for the Companies OU:

The "Authenticated users" group is deprived of the "List content" right on the "Companies" OU:

We continue with the "CompanyA" OU. The rights of the "Authenticated users" group are also changed here:

In this case, the "List content" and "List object" rights are removed:

The shadow group "SG-FirmaA" is now used for the CompanyA OU. An authorization is added for the CompanyA OU:

The "SG-FirmaA" group is now assigned the "List content" and "List object" rights:

The users of companyA are now added to the "SG companyA" group:

It is important that all users of the respective companies are always members of their shadow group. All users of CompanyA must be members of the "SG-CompanyA" group:

The configuration is now complete for companyA. The respective steps must now be repeated for companyB. It is advisable to prepare corresponding scripts here.

For special OUs

The content of the OU Shadow Groups can also be hidden from the user's view, in the same way as described here for other OUs. It is not recommended to adjust the rights at domain level. To assign the content of the "Shadow Groups" OU, the authorizations are adjusted again:

The "List content" and "List object" rights are withdrawn from the "Authenticated users" group:

For new / future OUs

To ensure that new organizational units are not directly visible to all users, the permissions in the Active Directory schema can be adjusted. To do this, the DLL of the "Active Directory schema" console must first be registered:

regsvr32 schmmgmt.dll

The DLL of the Schema console was loaded successfully:

The standard authorizations for newly created OUs can now be adjusted in the MMC snap-in "Active Directory Schema". To do this, the "organizationalUnit" class must be selected:

Here, the "List content" right is also withdrawn from the "Authenticated users" group:

New OUs are therefore created without read authorization for all users.

Optional: Customize UPN

Customizing the UPN is optional, but is usually simpler and easier for users to understand. A user from company A does not have to log in with username@cloud.frankysweb.de, but with username@firmaa.de, for example. Ideally, the user name corresponds to the user's e-mail address. Logging in with "e-mail address and password" is usually more intuitive for users than "Windows user name and password".

Alternative UPNs can be added in the "Active Directory Domains and Trusts" console. In this case, "firmaa.de" and "firmab.de" are added:

The users of companyA are now assigned the suffix "firmaa.de". Users from companyB are assigned the suffix "firmab.de":

In this case, the login name for the user Frank is "frank@firmaa.de".

Optional: Delegate administration

Simple administrative tasks can be delegated to other people. For example, if there is first level support in the respective companies, this person (or group) can be granted the right to take over certain tasks in the Active Directory. The "Assign object administration" feature can be used for this purpose:

The "CompanyA-Admins" group is selected here:

The next step is to define what the members of the "CompanyA-Admins" group are allowed to do:

Once the wizard has been completed, a member of the "CompanyA-Admins" group can perform simple tasks in the Active Directory:

For later tests, I have assigned the "AdminFirmaA" account to the "FirmaA-Admins" group.

These tasks can also be wonderfully automated using PowerShell Script.

Tests

It is interesting from the user's point of view. Here is the login with the user "Frank from CompanyA" with an alternative UPN. Frank logs on to a computer with his user name "frank@firmaa.de":

If Frank now searches the Active Directory, he sees the OU Companies and CompanyA. The CompanyB OU is not displayed:

Frank is now also unable to delete users from companyB. A search for "Hans from companyB" in the Active Directory returns no results.

The situation is similar in the "Active Directory users and computers" console. The "Administrator of companyA" (AdminCompanyA) only sees his respective company and can perform simple tasks there. Users from companyB are not displayed. Although the admin can now adjust group memberships, he remains in "his company", i.e. he cannot assign accounts from companyB to groups in companyA:

Notes

As you can see from the article, this procedure for separating companies or departments is not a trivial setup. Proper documentation on authorizations, shadow groups, inheritance, etc. is a MUST here. To ensure that authorizations and groups have uniform names, it is advisable to directly create corresponding scripts that automatically create new companies, OUs, groups and authorizations according to the standard. An Identity Manager would certainly be an advantage here.

Global administrators should always bear in mind that inheritance to the "company OUs" has been interrupted. Services and applications that assign the corresponding authorizations at domain level can no longer inherit these authorizations to the "company OUs". A subsequently installed Exchange Server can therefore not pass on its necessary authorizations to the "Company OUs", in which case it must be adjusted manually.

There are also other points to consider here that are not covered in this article. For example:

• How and in which OU are computer accounts created?
• How are group policies handled?
• What about access to other shared services?
• ...

The approach described here might be one way of implementing such requirements.