Microsoft Webcast
KB 287061
Search This Blog
Feb 23, 2005
Feb 7, 2005
High-Water Mark vector, Up-to-dateness vector, USN, and AD replication
see the following for what they are, how they work together
http://support.microsoft.com/servicedesks/webcasts/
en/wc020800/wct020800.asp?SD=gn&LN=en-ca&gssnb=1
http://support.microsoft.com/servicedesks/webcasts/
en/wc020800/wct020800.asp?SD=gn&LN=en-ca&gssnb=1
AD Object Permission Inheriting Behavior
================================
By default, permissions are inherited in AD. What it means is if you create a new object, it will get its ACLs from its parent container and the default ACL defined by schema for the class. For example, if "everyone" has "read" permission on an OU, then by default, "everyone" has "read" permission on any newly created downlevel OUs and objects.
You can change this behavior by clearing the checkbox "allow inheritable permissions....." on an AD object's properties windows, Security page. But as I said earlier, that box is checked on everything by default. If you delegate control to a group or a user on a specific level, the user/group is being delegated will automatically gets the same permissions against the downlevel objects.
So far everything what I have said should still make sense to you. And you would logically think that if you open the properties of an OU, add a user to have write permission, you should see that that user has write permission on downlevel objects. Surprisingly, that is not the case!
Hmm..., what is wrong here? So the inheriting model doesn't work anymore? Confusing, uh?
To understand all these, you have to understand that AD doesn't "copy" everything it has on one level to next level. It copies only "inheritable permissions" to downlevel. Then what is a "inheritable permission"?
If you click on Advance button on Security page, you will see the details of permissions on this object, each single entry(ACE) has an attribute of "this permission applies to", and the options are "this object only", "this object and the children", etc. Now you should have a kind of sense how it works, right? Change the type to be "this object and the children", you will eventually the permission you defined on this level will populate into downlevel object - as expected. And Delegation Control Wizard will take care of this for you.
By default, permissions are inherited in AD. What it means is if you create a new object, it will get its ACLs from its parent container and the default ACL defined by schema for the class. For example, if "everyone" has "read" permission on an OU, then by default, "everyone" has "read" permission on any newly created downlevel OUs and objects.
You can change this behavior by clearing the checkbox "allow inheritable permissions....." on an AD object's properties windows, Security page. But as I said earlier, that box is checked on everything by default. If you delegate control to a group or a user on a specific level, the user/group is being delegated will automatically gets the same permissions against the downlevel objects.
So far everything what I have said should still make sense to you. And you would logically think that if you open the properties of an OU, add a user to have write permission, you should see that that user has write permission on downlevel objects. Surprisingly, that is not the case!
Hmm..., what is wrong here? So the inheriting model doesn't work anymore? Confusing, uh?
To understand all these, you have to understand that AD doesn't "copy" everything it has on one level to next level. It copies only "inheritable permissions" to downlevel. Then what is a "inheritable permission"?
If you click on Advance button on Security page, you will see the details of permissions on this object, each single entry(ACE) has an attribute of "this permission applies to", and the options are "this object only", "this object and the children", etc. Now you should have a kind of sense how it works, right? Change the type to be "this object and the children", you will eventually the permission you defined on this level will populate into downlevel object - as expected. And Delegation Control Wizard will take care of this for you.
Feb 3, 2005
seemingly simple, namely "stupid", but hard-to-find-answer questions for beginners.
=========================================
More than often I was confused by a very basic concept that may be too simple for a guru but I just couldn't find a definite/clear answer ANYWHERE, and it slowed down my learning progress a lot. So, I am listing a few below, hoping that can help others who are experiencing similar problems.
1. do I have to have a MX record on my internal DNS for Exchange servers?
Answer: no. You don't. MX record is used only for people from Internet sending email to your organization.
2. Local Administrator, Domain Administrator, Administrators, and Domain Admins
1). "Administrator" is a built-in account that you can't disable/delete but can rename
2). If you are in a domain, you will have both "domain\administrator" and local "computer$\administrator" account. The one you see in Active Directory Users and Computers is domain administrator, while the one you see in Local Users and Groups is local Administrator. Note: on a Domain Controller, there is not Local Users and Groups anymore, and you will use only the one you see in ADUC, which is domain administrator (having local administrator permissions at the same time)
3). "Administrator" is not the same as LocalSystem
4). "Administrators" is a built-in local group for local administrators. "Domain Admins" is a built-in group for domain administrators.
5). By default, member of "domain admins" is also member of local "administrators"
6). You can put any one into "domain admins" and "administrators", they then get the permissions respectively
More than often I was confused by a very basic concept that may be too simple for a guru but I just couldn't find a definite/clear answer ANYWHERE, and it slowed down my learning progress a lot. So, I am listing a few below, hoping that can help others who are experiencing similar problems.
1. do I have to have a MX record on my internal DNS for Exchange servers?
Answer: no. You don't. MX record is used only for people from Internet sending email to your organization.
2. Local Administrator, Domain Administrator, Administrators, and Domain Admins
1). "Administrator" is a built-in account that you can't disable/delete but can rename
2). If you are in a domain, you will have both "domain\administrator" and local "computer$\administrator" account. The one you see in Active Directory Users and Computers is domain administrator, while the one you see in Local Users and Groups is local Administrator. Note: on a Domain Controller, there is not Local Users and Groups anymore, and you will use only the one you see in ADUC, which is domain administrator (having local administrator permissions at the same time)
3). "Administrator" is not the same as LocalSystem
4). "Administrators" is a built-in local group for local administrators. "Domain Admins" is a built-in group for domain administrators.
5). By default, member of "domain admins" is also member of local "administrators"
6). You can put any one into "domain admins" and "administrators", they then get the permissions respectively
Feb 2, 2005
what is userenv.dll?
When you are troubleshooting logon or Group Policy issues, you will very likely see event ID coming from userenv in your system log. What is userenv then?
Userenv.dll is a the Group Policy Engine that applies policies to your computer and your account. It calls different client-side extension to process different portion of your group policy. The most common CSE's include registry(administrative templates), security templates, folder redirection, software restriction, and so on.
Each CSE has a corresponding DLL to process the settings except registry CSE, which is process by userenv.dll itself.
If there is something wrong with your Group Policy application, possible causes include name solution not working, AD replication broken, FRS replication broken, and/or permission issue, you are very likely to see error reported from source "userenv" in Application Log.
To troubleshoot this kind of error, besides reviewing Event Viewer and collecting other basic information, most of the time you will need to enable User Environment debugging level to get more details.
Key: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon Value: UserEnvDebugLevel
Value Type: REG_DWORD
Value Data: 10002 (Hexadecimal)
Userenv.dll is a the Group Policy Engine that applies policies to your computer and your account. It calls different client-side extension to process different portion of your group policy. The most common CSE's include registry(administrative templates), security templates, folder redirection, software restriction, and so on.
Each CSE has a corresponding DLL to process the settings except registry CSE, which is process by userenv.dll itself.
If there is something wrong with your Group Policy application, possible causes include name solution not working, AD replication broken, FRS replication broken, and/or permission issue, you are very likely to see error reported from source "userenv" in Application Log.
To troubleshoot this kind of error, besides reviewing Event Viewer and collecting other basic information, most of the time you will need to enable User Environment debugging level to get more details.
Key: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon Value: UserEnvDebugLevel
Value Type: REG_DWORD
Value Data: 10002 (Hexadecimal)
Subscribe to:
Posts (Atom)