Published by
Ulf B. Simon-Weidner
TrackBack
Directory Services/Active Directory
Swami
Praveen
Steve
Victor
Ryan
Reload Nuggets » Blog Archive » Checking the AD “tombstone” in Windows or SBS 2003
kini
Eric Fleischman
Gil
Im my last blog post I mentioned how you are able to use conditional forwarders to forward request to
Congratulation.
acchong
That would be because in Vista, changes to WMI allow you to iterate in the array in VBscript much easier. This would affect anything written in the old way. Check out Scriptcenter for articles on new Vbscript and WMI methods in Vista.
James Pogran
Hi Ulf,
it's exactly the other way round: The German spelling uses the hyphen, the English spelling does not.
And - why don't you just use the service name instead of the display name? "net stop dnscache" stops the DNS Client service on every machine, no matter what its language is. You can find out the service names in Control Panel or by just querying "sc query" (or, more sophisticated: sc query|find /i "_name"). The most common names will surely burn into your mind quickly. ;-)
HTH & regards, Nils
Nils Kaczenski
Hi Nils,
shouldn't write posts that late - I first had it the correct way, then wanted to make sure and checked on my own machine. However I'm in a dual boot configuration right now - XP was in German, Vista in English, and I'm 99% working with Vista. So I mixed it up and thought that I'm on a German OS, woundered and changed the hypens .
Never mind - thanks for letting me know and I'm changing the post now.
The other thing you mention - yes - I know I could use the service name, but for whatever reason I'm just to lazy to keep them in mind and don't mind typing - so I'm usually using the Services displayname. No clue why - my brain prefers it this way - and there are more important things to remember.
I still don't understand why they are "semi-translating" certain things which are totally useless. Currently the name is english but the hypenation is german. Feels like eating ice-cream to fast: brainfreeze - outch.
PingBack from http://dnsserver.jsblogs.biz/article/653876/
Dns serverWeblog
PingBack from http://www.w2k.pl/longhorn-i-zasady-hasel/
W2K.PL » Blog Archive » Longhorn i zasady hase??
Ulf (DS MVP) who is now having a lot of fun during MVP summit with other MVPs (I'm really jealous) found
Tomek's DS World
What a pity! To me it seems they just added complexity and missed the chance to add security. Why not implement sophisticated filters that check newly created passwords against a more complete set of criteria - such as dictionaries (a simple yet powerful way to avoid trivial and standard passwords) and all-too-simple variations of common passwords? The filtering functions you describe still allow trash passwords like "aaaaa1!" or the like.
So we still have to go for common password filters. I hope at least they did not cut the interfaces to do that.
Somewhat disappointed, Nils
I can't imagine that this will make the front page of People Magazine , but if you are a Network or Security
Musings, Ramblings, and the Occasional Useful Information
Heh...Said wireless implementation is not exactly bullet proof either. You can use it without paying without all that much trouble.
Brian Desmond
while you are right that it would be nice to allow additional settings (grade of complexity, dictionary compares,..) I still believe that this is going in the right direction. What we get for now is less domains for password policy reasons, and a more granular way to decide which users should have which settings when it comes to lockouts and length. This is handy to differenciate regular users, admins, service accounts,...
If you want to add additional criteria which is not in Windows today at all, you'll have to stick with custom filters - and the risk for doing this. I think a password campaign in your company serves you better than a technical compare to dictionaries. There are enough interfaces out there which you are unable to influence (websites, 3rd-party apps) so your users should get taught what a good password is. Also creating a custom passflt.dll (IMHO) is a technical risk - it could blue-screen your DC since it's pretty deep in the system. Added features (like dictionaries) might increase the risk of a failure, which might leave your DC in a unstable state.
To answer your question, if you'd still be able to use a custom filter: as far as I know Yes. However if you want the added features described in this post you might need to get a new version of your filters as well, which take these settings into credit.
Ulf
Nice post Ulf - this comment is similar to what I posted on ActiveDir.org where this feature is also being discussed right now. The discussions often mention the need of a UI to manage it.
I don’t think that administrators will need much of a UI to configure password policy – a useful cli-tool should do, as I don’t see this used for too many different policies in a company. There may be exceptions where companies want to configure extra strong policies for (non-admin) users working with more sensitive data, but I don’t expect more than maybe 3-5 policies in most companies (…keep it simple…)
So while the challenge is not necessarily configuring the policies (even works quite fine with ADSIedit – you only have to get over the time-conversion quirk), it will certainly be understanding the active policy for a specific user, for example when a user calls the helpdesk because he or she has an issue setting a new password… (I can hear them already asking the helpdesk why his 8 char password is not accepted…) How will the helpdesk know which policy applies to the user? What if it’s one that doesn’t have the default domain policy but instead is member of a group that a specific Password Settings Object (PSO) has been applied to?
This info is easy to retrieve, but it’s not available easily in the current UIs - the following two attributes will retrieve the required data:
* ms-DS-PSO-Applied => this is a Backlink attribute of a user or group object (corresponds to the ms-DS-PSO-AppliesTo ForwardLink of the respective PSO object) and returns the DN of all the PSOs that are directly linked with the user or group. Note that multiple policies can be applied to a user or group and you’d need to run a query over the various groups and nested groups to determine all the PSOs that are applied directly and indirectly to a user and then evaluate the one with the highest priority/precedence. You’d first want to check If a policy is applied directly to a user as this always takes precedence over any policy applied via a group.
* ms-DS-Resultant-PSO => this a constructed attribute for users that return the DN of the one resultant password policy that is applied to the user – you do not need to add any additional logic to find the right PSO, as this is what the system has already evaluated in the background.
Both values only return the DN of the respective PSO => the PW related attributes of the PSO still need to be read and displayed appropriately to be helpful to the admin/helpdesk folks. This is where I expect the need for a UI to be more important – administrators and helpdesk folks will need a simple UI to show the Resultant-PSO and its values of a user. There is not much magic involved in this task, but one that simply needs to get done. It may be best to simply add a small VB script to the ADUC context menus of a user object via display-specifiers to show these values.
Note that these attributes are not part of any of the existing permission property sets; by default only members of domain admin group have access to the ms-DS-Resultant-POS attribute and PSO objects – as such this is one more thing to consider when delegating rights for other folks to read (or potentially edit) the password policies.
All in all I believe this is a very powerful feature - even though not all companies will need it. Especially those that try to get rid of the need of user's typing in their own passwords directly: moving to SmartCards will further increase security and won't require multiple PW policies...
cheers,
Guido
Guido Grillenmeier
Windows Server Longhorn will support three forest functional levels: Windows 2000 à W2K DCs and higher
Jorge 's Quest For Knowledge!
Late on Wednesday, as part of our commitment to deliver regular updates of Windows Server "Longhorn"
Windows Server Division WebLog
Uma limitação conhecida do Active Directory é a de ele suportar somente uma única política de senhas
Segurança na Microsoft
Od lutowego CTP dostępne są ziarniste polityki haseł - czyli możliwość przypisywania polityk haseł do
Windows Server Code Name "Longhorn"
pkrzysz blog