March 2007 - Posts
Another Article of Jorge mentions the new "Attribute Editor" in Active Directory-Users and -Computers (ADUC) and Active Directory-Sites and -Settings (ADSS). Basically you have the Property-Page of ADSIEdit now in ADUC and ADSS and you are able to configure all attributes of the selected Object in a more generic view. I love this "feature" (*) - you'll see it as soon as you have selected "Advanced View" in ADUS or ADSS and open a property page of a object.
Also I'd like to mention another great "feature" (*) of the property page - it shows you some of the data more human readable than it was in ADSIEdit. They are converting numbers now - e.g. to time-values a.s.o.
Another thing which has improved in ADUC is that if you select a domain controller you are able to access the NTDS-Settings-Object underneath it. For example you are able to configure the DC to be a Global Catalog (or not) on this dialogbox. This was providing a lot of confusion in the past where you either were able to see the DCs Properties in ADUC or to select whether it's a GC or not in Active Directory-Sites and Settings - so well done Microsoft for deciding to show it in Active Directory-Users and Computers as well.
Jorge is also covering LDP in his post, and how much it has improved. What I really love in LDP is the Advanced Security Dialog which displays a Security Descriptor with it's DACL, SACL and ACEs in the GUI or via a Text Dump. Just select Browse -> Security -> Security Descriptor out of the menu in ldp.exe and select the object and if you prefer a Text Dump or the "friendly view".
Read Jorge's article on Windows Server "Longhorn" - Management tooling to get more information about the possibilities in Active Directory-Users and -Computers and Active Directory-Sites and -Services.
(*) In Windows Server "Longhorn" we have Roles which we install, such as DNS-Server, Active Directory Domain Services, File Server, ... and Features which are minor things to install such as Bitlocker, Telnet, Windows Backup, ... so what do we call something which is a new thing but is not a Role or a Feature in the Product? In the past we've called it feature, but now we are without a wording for it.
Jorge's Quest for Knowlege is currently covering a lot about the next Windows Server "Longhorn" which is due later this year.
In his Post Windows Server Longhorn - Installing, Removing and Upgrading to AD he is covering a lot of the options you get with the new dcpromo in Windows Server "Longhorn".
I refer to this as the "Next -> Next -> Finish"-Consultant-proove Version of DCPromo. You know - Active Directory is a pretty complex topic, however there were many people out there who claimed to know Active Directory because they are able to install it using DCPromo. But it requires a lot more than that.
Microsoft basically took care of the "common Admin" by putting many of the best practices right into DCPromo, so if you are installing Active Directory by default now you'll get much more what you've set afterwards as default, so I do expect that we are getting less calls from Scenarios which lack best practices.
However you are still able to run dcpromo and configure many settings (actually much more) by selecting the advanced installation right on the first screen of the dcpromo-wizard.
If you have access to the beta or to MSDN - give it a try to explore the new dcpromo-wizard - you'll love it!
Read Jorges article where he tells you more about Installing, Removing and Upgrading to AD in Windows Server "Longhorn"
I recently got permissions to blog about some of the features which are not as well known in the next version of Microsofts Server Operating System: Windows Server "Longhorn". So let's get started. One of them is that in Longhorn, you are not limited to implement a single Set of Password Settings to the whole domain (and therefor implementing different domains if you need different Password Settings), you are able to apply Password Settings on a Group and User basis. This is really great - I've had multiple companies who - for example - wanted to implement different password policies for administrative accounts.
After migrating to Windows Server "Longhorn" on their DCs, they are able to incorporate this feature.
For those of you, who wanted to implement it using OUs or GPOs, read the "appendix" 
Which is important - this feature is available to you today - if you have MSDN or if you are a Betatester you already have access to the February CTP (IDX02) which is providing you with that feature, so you are able to test it (don't implement Windows Server "Longhorn" in Beta in your production until being advised by Microsoft in a TAP-Program).
You are able to configure the Password Settings and Account Settings like in Group Policies, but on a granular level.
So how do you get it?
The basic concept is, that there's a new object in Active Directory - the "Password Settings Object" which it's LDAP-Name msDS-PasswordSettings. For a new set of Password Settings - you simply create one of those objects underneath the container "cn=Password Settings, cn=System, dc=example, dc=com". You can do this using adsiedit.msc and you'll have to fill in the mandatory attributes, which are listed in the following table:
Attribute | GPO Branch | Meaning |
msDS-PasswordSettingsPrecendence | Password Setting | This is just a virtual number you can make up (make sure you leave some space in the numbering for future use) which defines which Password Settings are taking effect if mulitple apply to the same object (user or group, but settings on the user will always precendence settings on the group).
This will usually reflect on the "level" of the settings object, e.g. if you have stronger settings they have a lower value, if you have higher settings you'll probably assing a higher precedence to them. |
msDS-PasswordReversibleEncryptionEnabled | Password Setting | This attribute is boolean and defines if you want to store the passwords of the accounts (to whom the Password Settings Object applies) in reversible encryption or not. The default and best practice is "FALSE" |
msDS-PasswordHistoryLength | Password Setting | This setting defines how many old passwords the user cannot reuse again (to prevent the user from changing the password back and forward to the same one, or changing it multiple times until he's able to reuse his old password).
The domain default is not to allow the last 24 passwords of that user. |
msDS-PasswordComplexityEnabled | Password Setting | This attribute is a boolean again, and defines if the password needs to be complex (does have at least three of the following character sets applied: lower letters, captial letters, numbers, symbols, unicode characters).
The domain default and best practice would be to turn it on (TRUE). |
msDS-MinimumPasswordLength | Password Setting | This attribute defines the minimum lenght of a Password in characters. The domain default would be 7 characters long. |
msDS-MinimumPasswordAge | Password Setting | Also msDS-MinimumPasswordAge does just what it's name suggests - defining the minimum age for Passwords. Minimum age is necessary to prevent a user changing his password x-times on the same day until exceeding the Password History back to the same value than before.
This is a negative number which you can compile/decompile using the scripts at http://msdn2.microsoft.com/en-us/library/ms974598.... as a guideline.
(domain default: 1 day = -864000000000) |
msDS-MaximumPasswordAge | Password Setting | And this is just the opposite and defines when you have to change you password. Also a negative number as above.
(domain default: 42 days = -36288000000000) |
msDS-LockoutThreshold | Account Lockout | Defines after how many failed attempts entering a password the user-object will be locked.
(domain default: 0 = don't lockout accounts after invalid passwords) |
msDS-LockoutObservationWindow | Account Lockout | After which time should the "bad password counter" been reset?
(domain default: 6 min = -18000000000) |
msDS-LockoutDuration | Account Lockout | How long should a password being locked?
(domain default: 6 min = -18000000000) |
Afterwards you just need to link the new Password Settings Object to a group or user-account. You can only link this to global groups, so make sure to verify the group scope first. To link the PSO to a global group or user you just need to add the distinguished-name (e.g. "cn=my group, ou=corparate groups, dc=example, dc=com") of the user or group in the attribute msDS-PSOAppliesTo of the Password Settings Object which you want to apply to the user or group. You can even prove it afterwards trying to change the (test)account by just resetting the password as Administrator.
So this is one of the great features coming with Windows Server "Longhorn" - I'm very excited about it!
Appendix:
How today's password policies are implemented is actually not really through Policies. Actually a policy which is linked to the domain-head (the domain object in Active Directory, or the symbol which reflect the domain in Active Directory-Users and -Computers and in other interfaces) will be written to attributes of the domain-head, and those are the only settings which apply to any domain accounts. Everything which is configured in GPOs and linked to OUs is just applying to the computer accounts underneath that OU, and therefore to the local user accounts underneath (not user accounts). So if the Password Settings would be applied to OUs and GPOs it would be a bigger design change, and I guess you'd prefer to get the feature with the next Version than whenever
I just traveled to Seattle to attend the MVP-Summit, and it's already been great to meet so many MVPs again in the Hotels and on the Streets. During the next days the highlights will be to see Bill Gates live again and have many discussions with the Directory Services Product Group.
One thing which really bothered my during my trip here: at the airport in Chicago I've looked at the wireless network, and on the instruction card it mentioned the follwing:
How can I configure my computer to optimally enjoy Wi-Fi?
Make sure to disable your VPN, ipv6, firewall and proxy before connecting. [..]
So are they really suggest taking off your firewall for optimally enjoying Wi-Fi? In a public hotspot? I honestly hope they are changing these instructions.
To be fair - on the other side they recommended to set the checkbox in the "Windows Firewall" to "Don't allow exeptions". While this is a great advice and assumes that the Windows Firewall is turned on (you are unable to set that checkbox if it's turned off) the sceenshot right next to it shows the Windows Firewall being turned off with the checkbox not set.
Time to redo the document I guess