September 2009 - Posts
The world is not as polite anymore as it was years ago. People are forgetting what was called “good behavior / manner”. And Powershell is entering the world and starting to monopolize in the world of scripting languages.
I think Powershell should show some level of social responsibility. And today, I’m taking action to change it:
I, Ulf B. Simon-Weidner, propose hereby that Powershell should be forced to show more social responsibility. Therefore I propose two actions:
- Any command executed should, by default, set the –whatif parameter
(This would prevent the commands from executing, it'll only tell us what it would do) - To really execute a command, the –please Parameter must be used, which will revoke the –whatif parameter.
Wouldn’t this be nice?
In Windows Server 2008 you are able to stop Active Directory-Domain Services using the services snap-in or by typing
net stop ntds
However, this is for servicing only and not a state where the DC is intended to be kept for a longer period. Stopping AD is intended for servicing NTDS where there is a need of a stopped AD (such as in Directory Services Restore Mode, DSRM) but where is no need of a completely flushed Memory and stopped dependencies. So what you can do are things like offline defragmentation of the database or moving the database a.s.o.
I think, this is a good feature. Yes, it would be great to do other things. Yes, it would be great to restore AD without going in DRSM. There are things which would be nice. However … it’s better than before, and that’s what is important.
I love to do things using scripts. I love to use a toolbox, some script I’ve used before. Imagine – in the past doing offline defrags of the Active Directory database would require to reboot into Directory Service Restore Mode, log on as local admin (=DSRM-admin) then run ntdsutil with the options to do offline defrag into new files, then copy the new files over the old ones, reboot again into full more.
However, in Windows Server 2008 and above it is as easy as stopping NTDS, offline defrag, moving, starting NTDS.
It is urgent that you keep in mind that you can stop NTDS, however it’s not ment to be there for a longer period.
However, three things which made me worry if this feature is not well understood:
- It’s not a state to keep for a longer period, not a replacement for recovery-DCs (which are turned off in the closet).
- Not a replacement for DSRM when it comes to System State Recovery / Authoritative Restore which a Backup restored. If you need to restore a system state backup, the only supported way is to do it in DSRM.
- Authoritative marking object which haven’t been replicated to the DC in question is OK, same goes for file-management operations other than restoring a backup (the content of the dit basically needs to remain the same)
- You can’t logon with the DSRM-Admin when NTDS is stopped. This was hitting – in the beta-timeframe – someone who had a single DC, stopped NTDS, speared some time (screen saver kicked in) and couldn’t log on. DSRM-logon is not possible by default with a stopped NTDS when there are not other logon-servers available (if they are, e.g. you have a second DC, they are authenticating you on the DC with the stopped NTDS).
DSRM-Admin (which equals to local admin on a DC) is only available on Small Business Server (by default) or if you modified the following registry-key:
HKLM\System\CurrentControlSet\Control\Lsa\DSRMAdminLogonBehavior
Value 0: DSRM-Logon only when in DSRM (default)
Value 1: DSRM-Logon only when NTDS stopped (or DSRM) (default in
Value 2: DSRM-Logon always
HTH, Ulf
I was just pointed to the blog of David Loder who’s pointing out that the Release Candidate of Exchange 2010 is changing the permissions enforced by AdminSDHolder to critical groups to allow Exchange Organizational Admins to change the group memberships of Enterprise Admins, Schema Admins, Domain Admins a.s.o.
OK, one of Microsoft Program Managers already responded, and I do agree that this is not a released product and pre-release versions are there for finding those bugs.
I’d just like to say:
@Ross: This is not that hard to fix:
- for existing OUs stamp it on their ACE (preferably top-level - if inheritance is blocked on lower levels check and point to an KB
- for new OUs change the defaultNtSecurityDescriptor of the OU-Class in the schema
- don't touch adminSdHolder ;)
The first one will make sure that existing OUs allow Exchange Admins to control Group memberships (actually I’d even like to discuss if this is necessary – usually group membership administration is not done in the same instance where groups are mail enabled – the first one would be a generic help-desk task, the second a Exchange-Admin task).
I’d also prefer – if OUs are touched – that if the organization decided to block security inheritance at one point that a new version of some software shouldn’t go beyond that point but respect the design but warn them about the consequences.
The second suggestion makes sure that new OUs will get the permissions by default when creating the OU.
The third suggestion makes me think about two things:
- is there no process for infrastructure critical changes as changing the adminSdHolder (I’d think that the Active Directory Product Group should be involved if something as this is happening, how should they ensure security if other groups are mangling around with their mechanisms)?
- why is this coming up in RC? If a product is at Release Candidate Level, it’s mostly finished and usually there are not this many changes approved afterwards (unless they are critical). I hope that this will be fixed!
Thanks David for finding this one, very interesting, and I hope it’ll be fixed!
See Davids Blog for his post
See my blog-post about AdminSdHolder
And since I wanted to mention this: if you are in Europe (or want to come), The Experts Conference (TEC) is in Berlin next week and it is THE place for Active Directory and Exchange.