03.04.2009
Windows Server 2008 Active Directory introduced a setting called Protect object from accidental deletion on all directory objects:
This was implemented to avoid accidentally deleting objects from the directory. OUs have this setting set by default. But what does it actually do?
When this setting is set a Deny access control entry (ACE) is added to the security descriptor of the object ("DELETE" & "DELETE TREE") and a Deny access control entry (ACE) is added to the security descriptor of the PARENT of the object ("DELETE CHILD"). The security principal associated with these ACEs is Everyone, and they apply to This object only.
So if we select to protect the OU company.com/Unit/Users from deletion the following will happen in the directory:
- The Users OU itself will get the "DELETE" and "DELETE TREE" DENY ACE set.
- The parent of Users, in this case the OU Unit, will get the "DELETE CHILD" DENY ACE set.
Quried with DSACLS.EXE this will look like this:
For the Users OU:
dsacls.exe "OU=Users,OU=Unit,DC=company,DC=com"
Owner: COMPANY\Domain Admins
Group: COMPANY\Domain Admins
Access list:
Deny Everyone SPECIAL ACCESS
DELETE
DELETE TREE
For the Unit OU (the parent of Users):
dsacls.exe "OU=Unit,DC=company,DC=com"
Owner: COMPANY\Domain Admins
Group: COMPANY\Domain Admins
Access list:
Deny Everyone SPECIAL ACCESS
DELETE
DELETE CHILD
DELETE TREE
If you want to set these ACEs yourself you can use DSACLS.EXE:
For the Users OU:
DSACLS "OU=Users,OU=Unit,DC=Company,DC=Com" /D "Everyone:SDDT"
For the Unit OU (the parent of Users):
DSACLS "OU=Unit,DC=Company,DC=Com" /D "Everyone:DC"
If your are still running Windows 2000 or Windows Server 2003, I highly recommend making this part of your standard steps for creating new OUs. You can also change the Active Directory Schema so that the ACEs are set by default when creating new objects. When I figure out how that is done I will update this post. 23.01.2009
Over the years I have been involved in quite a few Active Directory deployments and restructures. On these projects much time is always spent, or should be spent, on designing the OU structure.
The main thing about OU structure desing is to keep thing simple. Some organizations like to take the organizational chars and copy that in AD. Chances are that that structure will not be very useful for the people whose job it is to manage the network. They need an OU structure that reflects groupings of users, computers, groups and servers which have the same management and configuration needs.
There are many approaches to the design process. Eg. geographical where your OUs reflect the geographical locations of your company or users and computers. Functional; which organizes users by the function they have in the company, for example Sales users etc. A much used variant is one where some or all of the regular approaches are combined, for example geographical and functional.
Now, let's consider an example. You have been charged with designing the OU structure for a large school or university. You decide that you want to use the functional approach and decided to create two main OUs to hold all your user accounts. The OUs will be called Students and Teachers. Upon first inspection this would seem to work well. You would be able to manage all your student users easily, same for teachers. But what if you have a user who works at the school as a teacher but would also like to attend courses or classes? (I assume here that we want to honour the principle of one user, one account.) That user should be treated as a student at one point, but as a teacher the next. Clearly our OU structure is not cut out for this. You could try to classify the user further and determine that he or she is mostly a teacher or mostly a student, but you probably do a lot of stuff based on which OU the user resides in, so you will eventually run into trouble. Not all your users will fit neatly into your two categories.
The problem here is that OUs are exclusive. You can only be located in one at any give time. So our desing here does not fit users that have dual identities. We have to come up with something that caters to this need. Back to the drawing board.
On our next try we start out with just one OU called Users. (Yes, I know there is already an object in Active Directory called Users, but that object is a container and we are creating an OU so that is not a problem.) In this OU we put all users regardless of their role or function. We now create groups to identify the needed roles. One group for students and one for teachers for example. We add all students to the Students group, all teachers to the Teachers group and users who are both to both groups. We now use Group Policy filtering to apply our GPOs to the correct group. A GPO that configures settings for students is filtered on the Students group, likewise for teachers. The GPO links that give the most access or have the least restrictive settings, should have a higher priority than more restrictive GPOs. That way if a user is a member of two or more groups with different access levels he or she will get the least restrictive settings.
Contrary to OUs, groups are inclusive, you can be a member of more than one. This lets your users assume several identities and get access to information and settings available to both.
I realize this approach is contrary to many accepted "truths" about Active Directory design, such that your should try to never filter your GPOs, but with the tools like GPMC it is very easy to see where your GPOs are linked and how they are filtered. 12.08.2008
Sometimes it is useful to be able to search for objects in Active Directory based on when they were created or changed, or both. The two attributes that hold this information are whenCreated and whenChanged, and they are present on all AD objects.
You use these two attributes like any other in you LDAP queries, the only thing to watch is the syntax of the date/time value. The syntax of both attributes is like this:
YYYY MM DD HH mm ss.s Z
2008 08 12 00 00 00.0 Z
(The capital Z at the end is mandatory and denotes Zulu time, which is the same as GMT.)
So to search for all users created on or after 12 August 2008 you use this query:
(&(objectClass=User)(whenChanged>=20080812000000.0Z)) 26.05.2008
The Active Directory GUID converter is now available as a stand-alone HTML Application (HTA) from the download page.
14.05.2008
This nice error popped up when trying to install ADMT v3 on a Windows Server 2008 x64 server:
---------------------------
ADMT Installer
---------------------------
The Active Directory Migration Tool v3 must be installed on Windows Server 2003.
15.04.2008
Trying to install a new child domain in an existing forest I received this error from DCPROMO:
---------------------------
Active Directory Installation Wizard
---------------------------
The wizard cannot gain access to the list of domains in the forest.
The error is:
The RPC server is unavailable.
A trace of the network traffic during the dcpromo process revealed a connection attempt from the local computer to one of the DCs in the root domain using the computername and username of the local computer. This of course fails since the local computer is to become the first domain controller in the new child domain and thus is in a workgroup. I could not see exactly what the local server was trying to connect to, so I started authenticating to the most common ones: IPC$, C$ and ADMIN$. Turns out it was ADMIN$ and after I ran this command, I was able to continue the dcpromo process:
net use \\<name of DC in root domain>\admin$ /user:<root domain>\<administrator in root domain>
Just as dcpromo was starting (after the summary screen) I received another error:
Managing the network session with \\<name of DC in root domain> failed
"Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again."
Dcpromo failed after this.
I restarted dcpromo and ran it all the way up to the summary screen. Before I hit Finish I ran this command to delete all connections to remote servers:
net use * /delete
Dcpromo could now successfully complete.
The Dcpromo log was also valuable in troubleshooting this, it can be found in %systemroot%\debug. 09.01.2008No, but I just had to try:
I wonder if this is just a mock requirement or if Enterprise edition really has any features that are required by IIFP, probably the former.
Morgan 30.11.2007
DCDiag (included in Windows Server 2003 Support Tools) reported a stange error at a site the other day:
C:\>dcdiag
Domain Controller Diagnosis
Performing initial setup:
***ERROR: There is an inconsistency in the DS, suggest you run dcdiag in a few moments, perhaps on a different DC.
This was accompanied by the following event in the Directory Services log on all DCs in the forest:
EntryType : Error
EventID : 1550
Message : The following site has no NTDS Site Settings child object.
Site: CN=SITE1,CN=Sites,CN=Configuration,DC=domain,DC=com
User Action
Create an NTDS Site Settings object for this site using Active Directory Sites and Services.
Category : Knowledge Consistency Checker
CategoryNumber : 1
ReplacementStrings : {CN=SITE1,CN=Sites,CN=Configuration,DC=domain,DC=com}
Source : NTDS KCC
TimeGenerated : 11/28/2007 5:41:06 PM
TimeWritten : 11/28/2007 5:41:06 PM
UserName : NT AUTHORITY\ANONYMOUS LOGON
Sure enough, the NTDS Site Settings and, altough not reported in the log, the License Site Settings object were missing from the site. After I recreated them and replicated the forest, DCDiag ran successfully and the messages in the Event log dissapeared.
As a footnote, the missing NTDS Site Settings object also resulted in the site not having an ISTG server and thus not being able to create inter-site replication objects. The site could only replicate with the other sites because of the existing connection objects, new objects could not be created. 15.08.2006
When you search Active Directory you have the option of asking the server to return search statistics for your query. This is done by adding an LDAP control to your query. The control is 1.2.840.113556.1.4.970. I was using LDP to test this out on my test forest. The forest runs Windows Server 2003 DCs and I use the W2K3 version of the Active Directory Administration Tool; LDP. In that version of LDP it is very easy to add the required LDAP control to the search, you just select it from a drop-down box from the Search Controls dialog.
I specifically wanted to see the expanded queries that the server extrapolates when using ANR searches, or LDAP Display Names in objectCategory searches. But to my surprise, the server never returned any statistics. I always got the same standard output; the result of my search and nothing more. After a little investigation I found the following text on the MSDN site:
To retrieve all of the above information [search statistics], the account that issues the LDAP request should have debug privileges in its token.
I remembered having tested PWDUMP on that particular server. PWDUMP requires the debug privilege to work. I had removed that from the Administrators group to test something with PWDUMP. When I gave it back and logged off and on again i could successfully see the search statistics from the domain controller.
Nice!
In Active Directory there is something called linked attributes. They exist in pairs, consisting of a forward-link and a back-link. The linked attribute pair member, of Group objects, and memberOf, of User or Groups is an example. In this particular case member is the forward-link and memberOf is the back-link. Back-links are always calculated automatically by the system whenever an attribute that is a forward-link is modified. If you change the member attribute of a group and add another object, the groups DN is automatically added to the memberOf attribute of the object you added.
I wanted to find out a little more about how this worked so I created a couple of scripts to do some testing. Specifically I wanted to see if I could write directly to a back-link attribute.
The first script tried to do that. It connected to an object in the directory and tried to write the DN of a group into the memberOf attribute. That failed with the error:
Code: 80072035
Error: The server is unwilling to process the request.
The next script connected to a group and added a user to it. As expected, that worked. I examined the user I added to the group in ADSI Edit and the back-link memberOf had been correctly computed. From that I can draw the conclusion that the computing of back-links is implemented in the DSA itself and not in the Admin tools (I was using a script, not ADUC, remember).
Next, I tried to edit the memberOf attribute of the user I had just added to the group directly in ADSI Edit. That provided the last piece of the puzzle and a conclusive answer to my question. Because that failed with the following error:
Access to the attribute is not permitted because the attribute is owned by the Security Accounts Manager (SAM).
So that was it. You cannot write to the back-link of a linked attribute pair. The back link is always automatically calculated and added by the system.
Also, the calculation and updating of a back-link attribute does not qualify as a change of the object. When I added a user to a group, only the group's whenChanged attribute was updated. The user's remained unchanged. That means that it is always the group object that is modified when you add a user to it. This seems obvious, but consider that you can also do this from the user's properties on the Member Of tab. What you are actually doing is editing the group object, not the user.
Ain't Active Directory fun! |
|
|
|
|