Today I’m going to talk a little more on Active Directory administration delegation to end users, or, at least, non AD Admins. We get a lot of questions along the following lines:
“We have a thousand end users, distributed over twenty different departments. Each department has its own public folder on our file servers. Whenever someone needs access to that public folder, or a sub folder, a call is made to our service desk, and someone from IT has to add a user to a security group. That work amounts to some X hundred calls a year, and worse, it’s prone to delays and errors. Do you offer a way to delegate this work to the department itself, but in a safe and straightforward way?”
Ehhh, yeah. Or better still, yes, we do!
Let’s break this question down a bit. What you want in this case is:
- to delegate this work to one end user per department. Let’s call these people Department admins. They do not need extensive, or even moderate Active Directory knowledge. They only need to know how to perform the specific tasks you allow them to do.
- you want each department admin to only have access to his or her department. So, you want them to only see the representation of their own department in your Active Directory. In short, you want to provide, and restrict to, a specific Active Directory Entry Point.
- you want to restrict what they can do to the objects in their own department. So, you want to allow them to modify group memberships, but not delete objects, or create objects, or see or change access rights, or change any other properties.
- You don’t want anyone except the department admin to even view you Active Directory, let alone change it, with any of our tools.
Here’s how to accomplish this with ADUC Admin Plus, for, say, department ‘Sales’:
- Create an ADUC Admin Plus profile with the name ‘Sales’, anywhere in your Active Directory.
- Under ‘Application Properties/LDAP’, pick the LDAP path to the Sales Organizational Unit, and restrict to ‘given LDAP path’ or to ‘given Domain’.
- Under ‘Application Prohibits’, check ‘disable Profile Override’ and ‘disable Profile Creation’. Also, check the ‘disable startup of all our tools by anyone who is not a member of any profile’ checkbox.
- Under ‘Function Prohibits’, disable all functionality.
- Under ‘Attribute Prohibits’, select all properties, except ‘Member’ and ‘Member Of’.
- With ‘Add Profile Users’, add the sales department admin to the profile.
That’s all there is to it. The result:
- Only the department admin can start up ADUC Admin Plus (make sure, by the way, you yourself are also member of a profile, or you also can no longer startup ADUC Admin Plus from anywhere in your network).
- When the department admin starts up ADUC Admin Plus, he or she only sees the subtree of the Organizational Unit ‘Sales’.
- Within that subtree, the department admin can only view Memberships, and he or she can only change memberships.
So, not only can you safely delegate providing access to your public folders to each department, there are three subsequent advantages:
Because our tools are single executables that do not have to be installed, you don’t have to install a client application to the workstations of your department admins. You also don’t have to install and maintain a (web) application to give your department admins access to your Active Directory. You can simply provide the executable itself, or the download URL, to your department admins, and you’re up and running.
ROLL BACK OF MODIFICATIONS
All changes made to your Active Directory by department admins are logged to an event viewer of your choice – and can be rolled back from that event viewer, by you, or, if you allow it, by the department admins themselves.
INTERFCACE IS ADJUSTED
When implementing the scheme above, no changes are made to the security on your Active Directory(!!!). The only thing you are doing, is restrict the interface and functionality of ADUC Admin Plus itself. In other words, if a department admin has the right to change, say, property ‘Description’, he or she still can change that property — just not with ADUC Admin Plus.
Although we strongly advise to always trim the rights you appoint to anyone on your AD, the question is basically irrelevant. Even if you make a department admin Domain Admin by mistake, he or she can still change only what’s presented to him or her. So, if you disable the option to delete objects, he or she can still delete objects, but not with ADUC Admin Plus, because the option simply won’t be available to him or her in ADUC Admin Plus.
We’ve had quite a few questions about the difference between Domain Local Groups, Domain Global groups and Domain Universal groups. So, here we go:
Domain Local Groups
- With Domain Local Groups permissions can only be assigned to resources in the same domain.
- Domain Local Groups can contain users, Domain Universal, and Domain Global Groups from any domain, as well as Domain Local groups from the same domain.
- Domain Local Groups can be a member of Domain Local Groups from the same domain.
Best practice: use Domain Local Groups to grant access to resources, such as you file systems. The reason being that you can add Domain Global and Domain Universal groups from any domain to a Domain Local group.
Domain Global Groups:
- With Domain Global Groups permissions can be assigned to resources in any domain.
- Domain Global Groups can only contain users and Domain Global Groups from the same domain.
- Domain Global Groups can be a member of Domain Local Groups and Domain Universal Groups in any domain.
Best practice: use Domain Global Groups to organize users who share similar access requirements, and make them member of the Domain Local Groups you use to grant access to resources.
Domain Universal Groups:
- With Domain Universal Groups permissions can be assigned to resources in any domain.
- Domain Universal Groups can contain users, Domain Global Groups and Domain Universal Groups from any domain.
- Domain Universal Groups can be a member of Domain Local Groups and Domain Universal Groups in any domain.
Best practice: use Domain Universal Groups when assigning permissions to related resources in multiple domains. Remember, though, that in forests with functional level 2003 or lower Domain Universal Groups are stored in their entirety in the Global Catalog, and are therefore replicated in their entirety across your Domain Controllers when you make one change to them.
So, when to use what scope? First, let me emphasize that Microsoft still insists on the best practices described above.
The whole scope differences originate from the good old NT4 days, when Microsoft networks only consisted of one domain. NT4 only knew Domain Local and Domain Global groups. Universal groups where created to support Active Directory and cross domain memberships, and in the early days they came at a price. Universal groups are stored in the Global Catalog, and if you changed them, let’s say by adding a member, the whole group was replicated across your Active Directory (basically, all the members were sent over the line to all Global Catalog servers, because a group’s memberships are stored as an attribute value in its members).
But things have changed since Forest Functional Level 2003 came into play, because since then only the changes are replicated, tremendously reducing the cost of using Domain Universal groups.
So, if your hardware and network bandwidth is ‘reasonable’ across the board (you have no Global Catalog servers behind very slow network connections), there is no longer need to shy away from exclusively using Universal groups.
There is one thing that you should not do, though: don’t use Domain Global groups to grant access to resources, for the reason stated above. You cannot add foreign users, Domain Local, Global or Universal groups to a Domain Global group, and so if you create another Domain in your forest, you cannot simply add users or groups from that new domain to your existing security structure.
If you run into this problem, don’t redesign your security structures.
Just use ADUC AdminPlus to convert your existing Domain Global groups …
Today I want to talk a little about access tokens, because there’s a lot of confusion about access tokens out there. When are they generated? What are they for? What problems are related with access tokens? What is a bloated access token?
Okay, first things first. An access token is created whenever a security principal (e.g. user or computer) is authenticated, when, for instance, a user logs on to a computer or attempts to access a resource. This is a little cryptic, but just realize that an access token is created upon any authentication attempt.
Let’s say that you need to open a file in a public folder. Access to this public folder has been restricted (by you or another admin) to a specific group of people. So, when you try to access this folder, a check must be performed whether or not you belong to this specific group of people, or rather, whether or not you are member of the Active Directory group that has been granted access to the folder.
This check is done by evaluating the access token that was generated when you logged on to your computer. And so, in order to perform this check, your access token must contain information about your group memberships, and not only that, but about your effective, or transitive, group memberships, because access to a resource can be granted by way of group nestling.
And so an access token contains the security identifiers (SIDs) of all groups the user or computer is effectively member of (well, not all of them, but more about that later).
In case you’re wondering why I’m saying ‘user or computer’: access tokens are also generated for computers. Microsoft is not very straightforward about this, but given that the Computer SchemaClass object inherits from the User SchemaClass, and that both use the same auxiliary securityPrincipal SchemaClass to generate a security principal, the access token build up and limitations for computer and user objects are identical.
The problem with access tokens is that they can only reach a certain size. An access token can only contain 1,024 SIDs (or, for the nitpickers amongst you, +/- 1,024 SIDs, because not all SIDs are the same size in bits, and a bloated token actually constitutes a buffer overflow problem). So, if a user or computer is effectively member of more than 1,024 groups, the access token becomes bloated, it’s creation fails, and consequently, authentication fails. If you’re lucky and are trying to log on interactively (i.e. logging on to a computer), you’ll see the following popup:
ERROR MESSAGE: The system cannot log you on due to the following error: During a logon attempt, the user’s security context accumulated too many security IDs.
If you’re not so lucky, and are NOT logging on interactively, but are instead trying to read your webmail for instance, you don’t see a popup. Authentication simply fails, and you are left to your own devices…
So, +/- 1024 SIDs, that’s the absolute limit? No. Actually, it gets worse. When logging on to Kerberos enabled IIS websites, or certain VMware platforms that use Active Directory Authentication, token encoding and HTTP header limitations come into play, leaving less room for SIDs, and so token bloat can occur beyond 200 SIDs (!!!).
Now’s the time to list which SIDs are actually included in an access token:
- The user’s or computer’s own SID, including SIDs from the SID history of the user or computer.
- The SID from each domain local group that the principal is directly or transitively a member of, for the domain of the workstation or resource.
- The SID for each domain global group that the principal is directly or transitively a member of, including SIDs from the SID history of the group.
- The SID for each domain universal group that the principal is directly or transitively a member of, including SIDs from the SID history of the group.
- The SID for each built-in group the principal is directly or transitively a member of.
- The SID for each computer local group that the principal is directly or transitively a member of.
- Explicitly NOT included are groups of type Distribution (Distribution Groups, or Distribution Lists).
Note that computer local groups are included in an access token, which is why someone might be able to log on to one computer, but not to the one standing next to it.
Given which SIDs are added to the access token, there are three common ways in which the access token limit is exceeded:
- Large fan-out group structure, where a user or computer is directly a member of many groups, or is a member of a group that is directly a member of many groups.
- Deep nesting group structure, where a user or computer is a member of a group that results in a large number of effective (transitive) memberships.
- SID migration. Since groups, as well as users, can have SID history, the access token of a migrated user with migrated groups can potentially have double the number of SIDs compared to a user that is not migrated.
It is our impression that access token problems are increasing. That shouldn’t be a surprise. Back in the NT 4 days, being effectively member of more than 1024 groups was quite an accomplishment. But nowadays, so much is integrated and handled by Active Directory, and forests can become so large that the accumulative number of memberships is, on average, gradually rising.
We have integrated access token calculation into ADUC AdminPlus. You can calculate the access token of individual users and computers, in which case you can see the origin of each SID in the access token, or you can calculate the access tokens of any set of users and computers via ‘View\Add/Remove Columns’… We have included the following, generated attributes:
- SIDs in Token
- SIDs in Token as SamAccountNames
- SIDs in Token as Number
- SID History SIDs in token
- SID History SIDs in Token as SamAccountNames
- SID History SIDs in Token as Number
Basically, this functionality allows you to scan your AD for users or computers that are on the verge of authentication failure due to bloated access token problems.
This is often the way things go: one of our developers came up with a ‘missing’ piece of functionality:
When requesting Foreign Domain Group memberships via the menu option by rightclicking one or more users, it could be useful to be able to remove the user from all these groups in a single action instead of having to open up all groups and removing the user per group.
The option to remove a member from a number of groups in a single action has been added. Select multiple groups, right click and choose ‘Memberships\Remove a Member form these Groups’.
It is incorporated in our latest build, 126.96.36.199, which can be downloaded from our website.
And, we are going to provide the option to have all memberships listed in the “MemberOf interface”, so, basically, to show all memberships across all domains, and make these memberships adjustable across all domains.
We have yet to decide whether we will enforce this as default, or as settable option via a profile. Before we decide this, we have to analyze workloads and timings in large environments (we have contacted a customer with 64 domains for beta testing). We hope to be able to offer this build somewhere at the end of next week.
What do you guys thinks? Give us feedback please…Default or Option?
DYNAMIC INTERFACING or ANOTHER WAY OF TASK DELEGATION
Today I want to talk about a specific dilemma: which tasks can you safely delegate to which line of IT defence?
The thing is, in most organizations a lot of tasks depend on security level rather than complexity, which means that relatively simple tasks can only be performed by relatively highly paid or skilled employees, simply because delegating those tasks would pose all kinds of threats to your network environment.
An example: You want your service desk to reset passwords and unlock accounts, both of which are fairly common tasks. In order to accomplish this, your service desk will somehow need access to your Active Directory, and it will need certain rights on your user objects.
So, in order to make your Active Directory available, you either need to grant access to a server to start up Microsoft’s ADUC, or you need to install the ADUC plugin onto certain workstations. Then you need to appoint the appropriate rights to your AD.
I’m not saying that this cannot be done. In fact, a lot of organizations solve this particular problem in this way. But let’s go through the implications of the different parts of this solution.
- Giving access to a server.
Simply granting Local Admin rights to a server to some or all of your service desk employees will not do, not even if you create a dedicated server. Service desk employees shouldn’t even have local admin rights to their own workstation, let alone a server. So, you will need to restrict their rights to starting an RDP session and starting Microsoft’s ADUC. This is still inherently unsafe, because being able to start an RDP session requires a lot more rights than you want to give away.
- Distributing the ADUC plugin.
Do you want all your service desk employees to be able to perform these tasks? If not, do your employees move around? You will have to restrict both install of and access to the plugin. It is difficult to make sure that your AD is only accessed by the right people.
- Appointing rights.
This can be done with great accuracy. You can either appoint individual rights or a set of rights directly (on OU level, for instance) or by way of Security Role Modelling. Still, a mistake is easily made, too many rights are all to easily appointed.
We have tried to tackle these problems and to take away at least some of the risks involved. Our solution is what we call ‘Dynamic Interfacing’ – allowing for delegation of tasks by offering tailor made interfaces. This means basically: if you want a certain employee, or group of employees, to perform a certain task, and only that task, then the interface makes only that task available to him or her when they fire up our tooling — wherever they fire up our tooling.
The methodology is as follows:
- First you create a security group anywhere in your Active Directory.
- Then you add some or all service desk employees as members to this group.
- Then, with ADUC AdminPlus, you convert this group to a profile. This simply means that an existing attribute is used to store ADUC Admin Settings.
Okay, and here’s the trick. The profile settings are implemented on all members of this profile, so that when a member of the profile starts up ADUC AdminPlus anywhere in your network, the interface is adjusted to the profile settings.
And what are these settings? You can decide to allow or disallow, and thereby show or hide, just about any functionality in ADUC AdminPlus.
An example. You want a certain group of people to do anything they want with ADUC AdminPlus, except delete objects. So, you create a profile, make these people member of this profile, and then you disable the delete option in their profile. And now, wherever they start up ADUC AdminPlus, and regardless of their rights to your Active Directory, the option to delete an object simply isn’t available to them in ADUC AdminPlus anymore.
You want to disallow moving objects? You want to disallow enabling or disabling objects? You want to disallow viewing security information? You want to make your entire Active Directory Read Only? You want to only make a part of your Active Directory visible and accessible? You want to disallow Exchange changes? You want to disallow the creation of objects? You want to restrict to one domain?
This way you don’t have to install any plugins or give access to any server anymore. You simply create a group, add your service desk employees to that group, convert it to a profile, disallow everything except making property changes, and ask your service desk employees to download the latest ADUC AdminPlus build.
When they fire it up, they can only change certain object properties. Any other functionality simply isn’t available to them. They cannot accidentally delete or move objects, or change or view security settings. That functionality simply isn’t present in the interface.
We have tried to make this as flexible as possible, but if you have specific needs that aren’t currently present, don’t hesitate to contact us or leave a note here, and we’ll try and build it for you
Today I’m gonna talk about a piece of functionality that we’re really proud of, because, far as we know, it didn’t exist before we created it. It’s called ACL scanning.
What, ACL scanning? You mean, like making a list of the existing ACLs on my file systems? Yes, that of course — and more. Or rather, different.
Extracting file system rights has been around for, well, probably for as long as there’ve been file systems. There’s CACLS, and there’s Powershell, and then there’s scripting. The one thing these all have in common is the conviction that this functionality is somehow best served by command line and export: a filter is constructed and the data is exported to some format or other, like excel or txt. From there you’re on your own.
But interpreting exported ACL data, especially of larger file systems, can easily make your head spin. The only solution, really, is some sort of GUI that allows you to refine your filter after the data has been gathered. This is the GUI we have developed, but the fact that it’s something new, especially in the ACL context, poses a problem: people don’t recognize it for what it is.
Some customers have been using ADUCAdminPlus for years, and still we have to point out this functionality to them. They’d seen the ‘Connect to File System for ACLs’ option but immediately dismissed it: “Ok, you can alter rights on a file system, so what?” But the funny thing is, changing ACLs is the one thing you cannot do with ADUC AdminPlus. But I’ll get back to that later.
First, here’s what you can do:
- As with any functionality in ADUC AdminPlus, you can reach the ACL scanning functionality by simply right clicking on a computer object in your active directory. When choosing ‘Connect/To File System for ACL’ an explorer like interface opens up.
- Next, by right clicking on a drive, share or folder, you can scan the computer’s file system up to ten levels deep. By doing this, all ACL information is collected. By the way, if rights are appointed more than ten levels deep you should seriously consider harassing your boss for ‘changes’ — if you can still remember his name, that is. I’m pretty sure that administering such a file system doesn’t leave room for sane thoughts. But that’s a different topic altogether.
- Next there are five basic filter options:
- filtering on inherited or explicit rights.
- filtering on found groups and users. By selecting a particular group, you can see instantly which rights have been appointed to which drives, folders or shares.
- filtering on any AD user or group. You can enter the name of a user or group object, and filter out the effective rights of this object. In this option, first the total effective group memberships of the given object are calculated, and this list is compared to the users and groups found during the scan.
- filtering on a list of users and/or groups. You can, for instance, compare fifty groups in your Active Directory against the found ACLs. So, let’s say you have a department with two hundred employees and a hundred security groups, and you want to find out which groups are no longer present in the ACLs of your a file system. You can select these groups in ADUC AdminPlus, export their AD names to a txt file, import them into the ACL scanning interface and check which groups are present or not.
- filtering on security level. For instance, you can show all users and groups that have Full Control rights anywhere on the file system. Or are denied write access anywhere on the file system.
The added value, of course, is that it’s very easy to combine all these filters, and prevent yourself from drowning in the collected data. In fact, the interface offers such a flexible way of filtering that you ‘see’ things you didn’t even realise existed. You can do some serious cleaning up, while remaining confident about your files system rights (you know, be confident that end users don’t start screaming about how they can suddenly no longer reach ‘That file that I’ve been working on all week!’).
Okay, that leaves changing the actual rights with ADUC AdminPlus, which, like I said, is the one thing you cannot do. Not because it difficult to build, because it isn’t, but because it can potentially lay waste to your file system rights.
Under the windows platform, ACLs are set on each individual folder and file. This means that if you change an ACL on a top level folder, it can take a long time for all ACLs to be set (don’t we know it). If you somehow interrupt this process, you end up with a corrupt rights system. So we would have to lock ADUC AdminPlus until such a process is finished, which is something we dislike in other tools, and hate in ours.
So, unfortunately, best practice remains setting file system rights on the computer on which that file system resides, if only because that’s much faster. You can add and remove members from groups that have been appointed rights to you file systems, but you cannot change the rights on that file system itself with ADUC AdminPlus.
The GUI is pretty cool, though. By no means rocket science, but pretty cool nonetheless. Oh, and by the way, you can also scan the ACLs on your Active Directory itself, with pretty much the same interface and the same options…
We all know about the divide between windows and linux. What always fascinated me about that divide is that (a lot of) fervent linux users simply hate all windows platforms, whereas (most) windows users aren’t so much hateful towards linux, but indifferent and too lazy to get to know (one of the) linux platforms. This also paints the power divide between the two platforms, especially in the working place.
One reason why windows is still the dominant platform in the working place is that linux does not offer a comparable way to maintain a single identity database — comparable to Active Directory, that is.
I’m sure I can hear some linux grumbles, but… as long as windows is dominant, why not use Active Directory to seduce people to start using linux? Because Active Directory can be used as a single identity database for linux users, meaning — it is possible to join linux computers to an active directory and allow windows users to log on to those linux computers with their windows credentials.
The way to go in this respect is using Winbind on the linux side in combination with ID mapping on the active directory side.
ADUC Adminplus offers 5 schemes to generate a unique uidNumber for users:
– From Store Object
– Generate Random Number
– Generate RID Number
– Copy Attribute Value
– Highest Number + 1
ADUC Adminplus offers 2 schemes to generate a gidNumber for users:
– GID from Primary Group
– GID from Group
ADUC Adminplus offers 4 schemes to generate a unique gidNumber for groups:
– From Store Object
– Generate Random Number
– Generate RID Number
– Highest Number + 1
If you need another scheme, don’t hesitate to let us know, and we will build it for you!
A common problem we come across when we visit customers, is that their file servers gradually fill up, no matter what they do. They ask (or demand from) their end users to regularly clean up their public folders, home directories and profiles. They scan their file systems for avi and mp3 files, but there’s no escaping it. Free space runs out.
Part of the problem is that over time file sizes increase (I think I read somewhere that word docs double in size every four years or so. And now we have a thingie called HD movie rips). Another problem is that home and profile directories are not always deleted when an employee leaves the organization.
There are perfectly understandable reasons for this. I think it’s safe to say that most admins hate this particular job, if only because deleting home directories is not without risk. Are you sure you can delete that home directory? Are you really really sure? Shouldn’t we move it to some, uh, backup place first?
And how can you be sure? Well, there are some criteria that can tell you with a fair amount of certainty whether or not a home (or profile) directory can be deleted.
5 Criteria for identifying obsolete directories
1. Does the folder name exist as a username? Most home and profile directories are named after the end user’s username.
2. If the folder name exists as a username, is this user object disabled or expired?
3. Does the folder name exist as a username in the ACL list? In most cases, the end user has been granted explicit access to his or her home directory.
4. Have any other users or groups been granted explicit access to this folder? Even if the original end user’s object no longer exists, others might still be using the home directory.
5. Finally, when was the last time the folder was written to? This value is only updated when a file or directory in the folder has changed.
So, if there is no corresponding username, or that username is disabled or expired, or that username does not exist in the folder’s ACL list, nor does any other user or group, and the folder hasn’t been written to for three months — then, I can tell you, that folder is no longer used by anyone.
With ADUC AdminPlus you can scan your file systems for obsolete home and profile directories, with the criteria above (and a couple of others). The space saved on deletion is also listed.
When we run this function on the file servers of our customers we can free up, on average (it depends a lot on the ethos of that one admin) about 10% of disk space. In an organization with, say 3000 employees, which all have, say, 10 gig of disk space at their disposal, that amounts to a lot of disk space. More importantly, this data does not need to be backed up every night (and backing up data is usually more expensive than the disk space itself).
There are a lot of questions out there about two Active Directory attributes, namely the Last Logon attribute and the Last Logon Timestamp attribute. First, let me list a few properties of both, and then I’ll get in to the implications.
- It is not replicated across domain controllers.
- For user objects, its value is updated each time a user physically logs on to a server or workstation.
- For computer objects, its value is updated when a computer authenticates to the domain, e.g. on booting, or on access token refresh.LAST LOGON TIMESTAMP- The Last Logon Timestamp attribute is not stored in the Global Catalog.
- It is replicated to all other Domain Controllers in the domain.
- It is not updated when the previous authentication request happened a shorter time ago then the value for the attribute ms-DS-Logon-Time-Sync-Interval (which is default 14 days).
- It is updated when a user or computer is authenticated by a Domain Controller, on interactive logon, and, for instance, when someone accesses his or her webmail, or accesses a network share.
Last Logon. An authentication request upon physical logon is handled by the domain controller that responds first, so such a request is not always handled by the same domain controller. This means that in order to obtain a user’s or computer’s true last logon, you need to query all your domain controllers. Authentication has priority over topology and active directory configuration, so even if you have designed your logon services so that a user can only authenticate to one domain controller, you will find that sometimes they’re still authenticated by another domain controller. So best practice is to always query all your domain controllers to obtain the true last logon.
Last Logon Timestamp.
The attribute was introduced with functional domain level 2003, so if you are still running domain level 2000, the attribute is not available to you. If your Domain Functional level is 2003 or higher, it suffices to retrieve the information from only one Domain Controller, but it’s accuracy depends on ms-DS-Logon-Time-Sync-Interval setting.
The reason why most people want to obtain these values is to find out if a user or computer object can be safely deleted. If you want to know when someone logged on to a computer in your network for the exact last time, search for the last logon value. If you want to know when someone last accessed a resource in your network (accessed webmail or one of your file systems etc), search for the last logon timestamp value. If you want to know when someone last used any network resource, search for the most recent of both values.
We now do this with AdminPlus, which you can try here
We regularly get the question if we can solve the following problem: a customer started out with an AD forest containing only a single domain. And because universal groups used to be rather costly in terms of replication between DCs before windows 2008 (in short, all the members of the group were sent over the line when a member was added or removed), they organized access to their resources (such as their file systems) via global security groups.
But then a second domain was introduced into their forest, for whatever reason (business expansion, business take-over, merging businesses, etc). And access to resources in one domain needed to be granted to users in the other domain.
But, users from one domain cannot be added as members to a global security group in another domain…
We see different costumers tackle this problem in the same ways. First they simply try to convert global groups to domain local groups. This works, but only for groups that aren’t themselves member of another global or universal group.
Next they decide to create a parallel group structure with newly created domain local groups, only to find out that this constitutes an immense amount of work. You will not believe the excel sheets we have seen — pieces of art in their own right. Art of the most depressing kind, that is. Because in order to recreate your group structure, you have to find out which groups have been granted access to which parts of your file systems. Once this new structure is implemented, you can never be sure that you have everything covered. So, apart from the work, a nagging ‘did we have it all’ remains.
1. Create a new Global or Universal Security Group.
2. Make the members of your original group member of this new group.
3. Make the new group member of the groups your original group was member of.
4. Remove the members from your original group.
5. Remove your original group from the groups it was member of.
6. Convert your original group from a global or universal group to a Domain Local Group.
7. Make the new group member of your original group.
Notice that you no longer need to find out which rights have been granted to which resources. The question is irrelevant, because the rights to your resources, such as your file systems, haven’t changed. Futhermore, your nestled group membership structure remains intact.
The only thing that’s changed is that your original group is now a domain local group, to which you can now add users from another domain, allowing you to grant access to resources in one domain to users from another domain.
You can follow the procedure mentioned above. The simplest way to perform this conversion, however, is with AdminPlus...
- ACTIVE DIRECTORY TASK DELEGATION TO END USERS
Today I’m going to talk a little more on Active...
- Domain Local, Global And Universal Groups
We’ve had quite a few questions about the difference...
- Access Token Overview
Today I want to talk a little about access tokens,...
- Remove a member from a number of groups in a single action
This is often the way things go: one of our developers...
- How to delegate Active Directory tasks for IT defense safely?
DYNAMIC INTERFACING or ANOTHER WAY OF TASK DELEGATION...