• RSS
  • Twitter
  • FaceBook

Security Forums

Log in

FAQ | Search | Usergroups | Profile | Register | RSS | Posting Guidelines | Recent Posts

Different Password Policies

Users browsing this topic:0 Security Fans, 0 Stealth Security Fans
Registered Security Fans: None
Post new topic   Reply to topic   Printer-friendly version    Networking/Security Forums Index -> Exchange 2000 // 2003 // 2007 & Active Directory

View previous topic :: View next topic  
Author Message
rheroux
Just Arrived
Just Arrived


Joined: 08 Jun 2005
Posts: 0


Offline

PostPosted: Wed Jun 08, 2005 7:03 pm    Post subject: Different Password Policies Reply with quote

Hello, my company wants to start enforcing a password policy for all of our users.

Our users are going to be required to change their passwords every 28 days. I know this is easily accomplished by simply going into the Domain Security Policy and defining it there.

However, I'd like to also have a a few users (around ten or so) excluded from this policy. I read somewhere that this isn't possible because the password policies can only be defined in the Domain Security Policy.

Is this true? The reason I want to have some users excluded is because they are primarily remote (VPN) users and I'm not sure how things would go over if they were to try and log onto our VPN server after there password had expired.

Thanks for any information.


Rene
Back to top
View user's profile Send private message
njan
Trusted SF Member
Trusted SF Member


Joined: 02 May 2005
Posts: 9
Location: Scotland, UK

Offline

PostPosted: Wed Jun 08, 2005 7:47 pm    Post subject: Reply with quote

Quote:
Our users are going to be required to change their passwords every 28 days. I know this is easily accomplished by simply going into the Domain Security Policy and defining it there.


First of all, two things:

on the topic of password policy: Are you sure that it's absolutely necessary to have users change passwords this frequently? In my experience battling these issues, the security offered by imposing password complexity/aging rules decreases drastically once you impose rules that are stricter than an 8-character alphanumeric password every 90 days - all of the evidence points towards users writing down their passwords and varying them trivially (changing a single number/character etc).

on the topic of group policy: The domian security policy edits one, master policy which is defined at the root of your windows domain and therefore affects all of the users on your network. Group policy is a powerful tool and domain policy is a good place to define network-wide settings which are the same for every single user, but this group policy object in particular needs to be treated with caution because any mistakes made here (such as mistakes which deny local logon, prevent use of privileges, etc) will affect all users including your administrative users.

To that end, if you're making changes like this, especially if they're either a) Not designed to affect all users, or b) Dangerous in nature (because they could affect a user or all users ability to reverse those changes), you should test them on an organisational unit or test domain first.

Quote:

However, I'd like to also have a a few users (around ten or so) excluded from this policy. I read somewhere that this isn't possible because the password policies can only be defined in the Domain Security Policy.


In continuation of what I mentioned above, it is (technically) possible to exclude users from the domain security policy by creating another policy which overrides it, but there is very little justification for doing this, and having policies which overlap in this manner is deeply, deeply bad and will cause your network to cry. Instead, what you should do is to create organisation units in the Active Directory Users and Computers mmc snapin / administrative tool which are well thought out and which affect different users in different ways - by keeping offsite users in a different OU to onsite users, you can create two group policies which contain settings which are not the same for all users, called 'onsite account policy' and 'offsite account policy' (or something similarly sensible), and apply the changes to each policy for the users inside that OU.

Quote:

Is this true? The reason I want to have some users excluded is because they are primarily remote (VPN) users and I'm not sure how things would go over if they were to try and log onto our VPN server after there password had expired.


They can't logon once their passwords hit the end of the 'grace' period and have fully expired - there's no way to easily reset passwords remotely like this without involving IT staff, or using an addon package designed either to do this or to do something else which allows you to change a password (I think I've heard OWA - Outlook Web Access mentioned in this capacity). The easiest thing is often to set the 'Password does not Expire' flag on these users accounts (again, in Active Directory Users and Computers) and make this a training issue (or make a note in your calender to tell these users specifically to change their passwords when they are connected to the domain.

If you're interested in learning more about Group Policy and how a well-structured Active Directory tree uses Organisational Units, there's plenty of information on these topics at the Windows Server 2003 Technet site.
Back to top
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger
zeedo
SF Reviewer
SF Reviewer


Joined: 01 Sep 2004
Posts: 24
Location: Scotland

Offline

PostPosted: Wed Jun 08, 2005 9:47 pm    Post subject: Reply with quote

njan's advice is all technically correct, but it doesn't apply to password policy. Password policy can only be set once for the entire domain, any password you set elsewhere will affect the local users of the servers within the domain, but will not affect the domain logons. If you need separate password policies then you need separate domains, in this case however you probably shouldn't create a new domain since it is only for a few users.

If the only concern is VPN users that use Windows as their desktop then you have nothing to worry about, when they VPN in they will still be prompted to change their password if it expires, just as they would logged on locally.
Back to top
View user's profile Send private message Send e-mail Visit poster's website AIM Address Yahoo Messenger MSN Messenger
rheroux
Just Arrived
Just Arrived


Joined: 08 Jun 2005
Posts: 0


Offline

PostPosted: Wed Jun 08, 2005 10:18 pm    Post subject: Reply with quote

Quote:

If the only concern is VPN users that use Windows as their desktop then you have nothing to worry about, when they VPN in they will still be prompted to change their password if it expires, just as they would logged on locally.


Okay, that's good to know. However, I store their user accounts locally (ie, they log onto the domain even though they aren't physically connected to the domain) so when they change their password will it automatically update their locally stored password as well?

On a side note, I can't believe that this is the way it works. Wouldn't Microsoft recognize that it would be entirely feasable for a company to want to have separate passwords policies for different groups?
Back to top
View user's profile Send private message
zeedo
SF Reviewer
SF Reviewer


Joined: 01 Sep 2004
Posts: 24
Location: Scotland

Offline

PostPosted: Wed Jun 08, 2005 10:23 pm    Post subject: Reply with quote

Store them locally?

If you mean they are domain users, then yes it is fine.
Back to top
View user's profile Send private message Send e-mail Visit poster's website AIM Address Yahoo Messenger MSN Messenger
rheroux
Just Arrived
Just Arrived


Joined: 08 Jun 2005
Posts: 0


Offline

PostPosted: Wed Jun 08, 2005 10:36 pm    Post subject: Reply with quote

Quote:

Store them locally?


Yeah. I go into Control Panel->User Accounts and add them to the local list of users and make them administrators of their local computers. (They're on the road so they need administrative access to install things sometimes.)
Back to top
View user's profile Send private message
zeedo
SF Reviewer
SF Reviewer


Joined: 01 Sep 2004
Posts: 24
Location: Scotland

Offline

PostPosted: Wed Jun 08, 2005 10:38 pm    Post subject: Reply with quote

Yeh, they are local admins, that is irrelevant. That isn't storing them locally that is just adding permissions locally. They are still domain users and their passwords are still stored on the domain, they should be able to use VPN and change their passwords without issue.
Back to top
View user's profile Send private message Send e-mail Visit poster's website AIM Address Yahoo Messenger MSN Messenger
njan
Trusted SF Member
Trusted SF Member


Joined: 02 May 2005
Posts: 9
Location: Scotland, UK

Offline

PostPosted: Wed Jun 08, 2005 10:48 pm    Post subject: Reply with quote

Quote:

njan's advice is all technically correct, but it doesn't apply to password policy. Password policy can only be set once for the entire domain, any password you set elsewhere will affect the local users of the servers within the domain, but will not affect the domain logons. If you need separate password policies then you need separate domains, in this case however you probably shouldn't create a new domain since it is only for a few users.


Ouch!

Quote:

Active Directory domains use GPOs to store a wide variety of configuration information, including password policy settings. Although Active Directory is a hierarchical directory service that supports multiple levels of organizational units (OUs) and multiple GPOs, password policy settings for the domain must be defined in the root container for the domain. When the first domain controller is created for a new Active Directory domain, two GPOs are automatically created: the Default Domain Policy GPO and the Default Domain Controller Policy GPO. Default Domain Policy is linked to the root container. It contains a few critical domain-wide settings including the default password policy settings. Default Domain Controller Policy is linked to the Domain Controllers OU and contains initial security settings for domain controllers.

(from this technet reference)

I didn't realise that! :/.. no password expiry it is, then!
Back to top
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger
rheroux
Just Arrived
Just Arrived


Joined: 08 Jun 2005
Posts: 0


Offline

PostPosted: Thu Jun 09, 2005 8:38 pm    Post subject: Reply with quote

Sorry to bug you guys again, one final question.

I've organized my Active Directory into various OUs, and one of them is called Remote Users.

If I create a GPO for this OU and check the Block Policy Inheritance checkbox, would this mean that the computers in the Remote Users OU would be excluded from the sitewide Password Policy rules as defined in the Default Domain Policy?

I'm just trying to figure out someway around this restriction... as most of you probably know salesmen are hard enough to deal with on a day-to-day basis without giving them yet another task to do. (And yeah, it should be easy enough but you should see some of the calls I get sometimes, heh.)
Back to top
View user's profile Send private message
rheroux
Just Arrived
Just Arrived


Joined: 08 Jun 2005
Posts: 0


Offline

PostPosted: Thu Jun 09, 2005 9:03 pm    Post subject: Reply with quote

Hmm, nevermind I think I may have found a solution.

Simply checking the Password Never Expires checkbox should override the ten or so users from having to abide by the Defaul Domain Policy right?
Back to top
View user's profile Send private message
njan
Trusted SF Member
Trusted SF Member


Joined: 02 May 2005
Posts: 9
Location: Scotland, UK

Offline

PostPosted: Fri Jun 10, 2005 1:47 am    Post subject: Reply with quote

Quote:

Hmm, nevermind I think I may have found a solution.

Simply checking the Password Never Expires checkbox should override the ten or so users from having to abide by the Defaul Domain Policy right?


Well..

Quote:

They can't logon once their passwords hit the end of the 'grace' period and have fully expired - there's no way to easily reset passwords remotely like this without involving IT staff, or using an addon package designed either to do this or to do something else which allows you to change a password (I think I've heard OWA - Outlook Web Access mentioned in this capacity). The easiest thing is often to set the 'Password does not Expire' flag on these users accounts (again, in Active Directory Users and Computers) and make this a training issue (or make a note in your calender to tell these users specifically to change their passwords when they are connected to the domain.


..yes.. Razz
Back to top
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger
AdamV
SF Mod
SF Mod


Joined: 06 Oct 2004
Posts: 24
Location: Leeds, UK

Offline

PostPosted: Fri Jun 10, 2005 10:34 am    Post subject: Reply with quote

It's time to clear up some confusion that exists in some of the books and training courses.
It is often stated that you can have only one account policy in the domain and it must be applied in the default domain policy, and that all other account policies don't work and can't be used.
This means if you want different policies you have to create a new domain within the forest and put the users in there (the domain is a security policy boundary, even though it is not a security boundary in other senses).

However, this is not strictly true - you can apply an account policy wherever you like and it will apply to all accounts (ie user accounts and even computer accounts where settings are relevant eg account expiry date) in that OU, site or whatever.
so what does this do?

It applies the policy to local accounts in that area (this was hinted at by a post above, but I thought it deserved more attention because it is often mis-explained).

Now here's the trick to all this.
Let us suppose you have a machine in a domain, and a domain user logs in. Let's also suppose the user is in an OU with an account policy applied for expiry and complexity, but there is no domain account policy (it is undefined or disabled)
The user's password will expire because the local account expires. When they provide a new password it must meet any requirements of the local account since the domain account is cached locally and is covered by the local account policy.

So to achieve what rheroux wants, I would suggest simply applying two account policies - one to the OU for remote users and a different one linked to the OUs for other users (just one GPO with several links). Make sure you either separate the OUs or very carefully use blocking to be sure what you will get. If you are not already using the GPMC to do all this, download it now.
You could just give these users non-expiry ticks, but I would suggest this is bad policy, but an extension is reasonable, I would also suggest you should enforce stronger passwords if they will not be changed as often.

I would suggest your normal domain users should have expiry, complexity, non-reuse and no part of name or logon etc.. Probably something like 60 days, 7 characters, complexity on, no reuse for 25 times. (2 ways to go for regular users IMO - complexity on OR >14 chars. I find users don't like typing the longer version so this is a balance of practicality/security. Domain admin accounts >14 AND complexity is sensible)

Your remote users MUST have strong passwords. Complexity on and possibly longer than normal users, but push expiry out to maybe 100 days. Make it policy that they should change their password every time
they visit a physical office (if they are not meeting a manager face to face once a quarter eg at sales conference I would be surprised).

Two gotchas that I know of with account policies:
Locking passwords after X wrong attempts does not seem to work in the above model. It seems to only apply properly when in default domain policy as per conventional wisdom.

I found (on a 2k domain with 2k and XP clients) that if you set password length to anything eg 8 characters, the error message that users get says "blah blah complexity or be at least 7 characters blah blah". The error message does not seem to reflect the detail of the policy. This may have been fixed now, test in your environment. (this is the only reason I would recommend 7, otherwise 9 would seem a feasible number)


Other things to think about:
If you have downlevel clients (NT4, 9x), read the articles on stopping LM authentication and force NTLM2 wherever possible, or NTLM if you can't. If you have 9x clients, make sure that when Windows asks to save the windows password that users blank this out and then say OK. (It will do a passthrough authentication to Windows if the domain password matches the windows one OR the windows one is blank. If users save it they get a problem downstream when they change it that they have to use two passwords to get in, so this is how you convince them to do this. From your point of view the problem is that it is stored in a .pwl file and that can easily be taken away and cracked).

I have been told but never tested for myself that if you change your password offline some of the policy does not apply eg you can create a non-complex password. I actually think in the case of the person who told me this, it was a remnant of NT4 domains and LM hashes (ie upper and lower case were the same). Test if this is important to you.

In NT4 user manager you could create any password you wanted, even when length and complexity was turned on. This was sometimes useful if you wanted to do a password reset for a user, ticked the box to say they had to change it immediately and you used a random 8 letter word (get a cheap remaindered crossword dictionary and keep it by your desk, cross them off as you use them).
In 2k this loophole was closed. If the policy applies to the user it applies all the time no matter how you change it. However, if you use my model rather than a domain policy you can move the user to another OU with no policy, change it, then move them back. This gets harder if you use delegated authority to allow first-line helpdesk to reset passwords.
It is easier to tell someone over the phone that their password is "starfish" than "St4rf!sh". That said, giving them a complex but not mad password (eg "1Starfish") can server as an example of how easy it is to choose a complex password in future. My favourites for this are "hdIrtpw?" and ""StG23Apr!". Much debate rages as to whether we should all forget about complexity and enforce a length of say 25, and get users to use passphrases instead (see here for example, or attend any MS conference /roadshow on security at the moment - you will get about a 50/50 split of opinion normally). Personally I find half of users can't type sufficiently accurately, so I tend to recommend thinking of a phrase (eg song lyrics) and using initial letters, corrupted a little to make it harder. "F!Iwtl4e!", "Wdiarom?", "6!6!6!TnotB".

Password lockout is only a good thing as long as your helpdesk can give appropriate level of user support (ie they answer the phone!). If you have any 2k clients I would suggest 4 tries is about right. If you have XP you can reduce this to 3 or even 2 wrong tries because of the helpful popup about having CAPS lock on, which seems to fix about half of this problem. (Thankyou Bill!)

If you have a TS / Citrix environment on different sites, make sure that you test thoroughly and educate users well - if they change their password at the first grace prompt on their local machine then try to log in to the remote box, the change may not have propagated. Then they use their old password. Then it propagates and they can't browse through the proxy. Then they can't print. etc etc <insert your own nightmare here>. If you use Citrix with a current version of the client and you use passthrough (a bit different to the old way it cached credentials and used them, it now does a "real" passthrough) this seems to be fine. If not, I would advise users to never change their password on the local box, always change it when they log into TS (obviously if they onlyuse one app now and again, or when remote, this advice would vary accordingly, I'm thinking of a full time desktop environment here really).

Acknowledgement:

Thanks to author and systems / security guru Roberta Bragg for finally clearing up some of this in my mind and explaining why I "broke" a domain account policy once. I had used the above model and it worked fine. Then we decided that since the policy had been applied to most OUs for ages and been working fine, we could safely move the policy up to domain level and nothing would change. I relinked the GPO to the domain and everything was fine. Until users started getting locked out. That's all that happened, password changes still worked, complexity was OK etc, but the lockout we thought had been in place simply was not (we just thought our users never got it wrong more than 4 times, not too unreasonable for a well-educated userbase). All the references I could find told me the original model could not possibly have been working, even though I had seen it with my own eyes for 2 years. "Hardening Windows Systems" cleared up the muddy waters.
Back to top
View user's profile Send private message Visit poster's website
browolf
Trusted SF Member
Trusted SF Member


Joined: 19 Apr 2002
Posts: 1


Offline

PostPosted: Wed Nov 01, 2006 12:47 pm    Post subject: Reply with quote

i cant seem to get it to work.... tried putting a user or a machine in the gpo.

what i want is to apply the policy to an ou of users.so got test ou test user, attached the main user gpo and the test gpo. so only fidling with the test gpo. just enabled longer passwords to start with.

turned on loopback as the password settings in the computer configuration. tried enforced, removing the user gpo all to no avail.

not sure where im going wrong.
Back to top
View user's profile Send private message
AdamV
SF Mod
SF Mod


Joined: 06 Oct 2004
Posts: 24
Location: Leeds, UK

Offline

PostPosted: Wed Nov 01, 2006 5:36 pm    Post subject: Reply with quote

it needs to be applied to machines, not users

loopack is not relevant

what's your domain and client OS?
Back to top
View user's profile Send private message Visit poster's website
browolf
Trusted SF Member
Trusted SF Member


Joined: 19 Apr 2002
Posts: 1


Offline

PostPosted: Wed Nov 01, 2006 8:20 pm    Post subject: Reply with quote

server 2003 / win2k workstations.

fortunately the users we want to have complex passwords use mostly laptops and the users that we dont want having complex passwords shouldnt be using any of the other user's laptops.

so i enable it on a laptops ou and if ppl log on to these machines when their password is up for change it forces them to have a complex one. And I just enable it in the gpo just like I would for any other item that i'd want applying?
Back to top
View user's profile Send private message
Display posts from previous:   

Post new topic   Reply to topic   Printer-friendly version    Networking/Security Forums Index -> Exchange 2000 // 2003 // 2007 & Active Directory All times are GMT + 2 Hours
Page 1 of 1


 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Community Area

Log in | Register