Re: How to /password policy on Windows 2003

[pent 5971]

Any ideas/best practices?

Regards

2009/8/20, pent 5971 <pent5971@...>:
> Hi,
> I have an important Windows 2003 box which we are using only a admin
> account actively. I also need to set a password policy (i have some
> requirements) on this box and dont loose the admin account acces. How
> can i do this password policy?
>
> Regards
>

[THOMAS, DEDRIC (ATTCLSMA)]

Hey,

It depends on what Industry Compliance you are following, each Industry has
it's own set of compliance standards, i.e. PCI, HIPAA, etc...  Review your
current policies and guidelines to determine what are the "BEST PRACTICES"
for your company.

Thanks in advance,

-----Original Message-----
From: listbounce@... [mailto:listbounce@...] On
Behalf Of pent 5971
Sent: Friday, August 21, 2009 8:14 AM
To: focus-ms@...
Subject: Re: How to /password policy on Windows 2003

Any ideas/best practices?

Regards

2009/8/20, pent 5971 <pent5971@...>:
> Hi,
> I have an important Windows 2003 box which we are using only a admin
> account actively. I also need to set a password policy (i have some
> requirements) on this box and dont loose the admin account acces. How
> can i do this password policy?
>
> Regards
>

[Rivest, Philippe-2]

Well first off, I would sadly say it depends a lot on your company and how
they view security, which requirements you have (legals and business).

Let's say you have a financial server (the 2k3 box) that will transfer
customers information for credit, maybe PCI needs to be applied. You need to
know this kind of things first.

Also, maybe this server has a higher security requirement than another (you
don’t specify). So if you're normal password policy states 6 char long for a
password, maybe you would want to go at 8-10 for this one if its more
critical.


I would also make sure your local admins cant bypass the policy, maybe push
it thru AD if you have it and they don’t have AD access? Putting it locally
and giving them local admin is not serious enough for a critical server. So
I would say in "Domain Policy" under admin tools in windows.

Password policy should come from the top (management, higher than Director)
and be applied to everyone and everything. It should be clear and short. 1
page max for a password policy should be more than enough.
-All passwords should be at least 8 character long
-All passwords should expire after 45days
-All passwords need to be complex (INSERT definition..)
...
Have the policy signed (*approved*) by upper management and than applied to
the 2k3 box.

Side note, the sentence with "loose" I didn’t understand it too much. But I
would also suggest limiting local admin access to a very few IT employees.
If they don’t need it don’t give it, all this has to be approved (as we all
know).

Hope I was on your topic, if not sorry :)

 
Philippe Rivest - CEH, Network+, Server+, A+
TransForce Inc.
Internal auditor - Information security
Verificateur interne - Securite de l'information

8585 Trans-Canada Highway, Suite 300
Saint-Laurent (Quebec) H4S 1Z6
Tel.: [phone]  
Fax: [phone]

http://www.transforce.ca/


-----Message d'origine-----
De : listbounce@... [mailto:listbounce@...] De
la part de pent 5971
Envoyé : 21 août 2009 08:14
À : focus-ms@...
Objet : Re: How to /password policy on Windows 2003

Any ideas/best practices?

Regards

2009/8/20, pent 5971 <pent5971@...>:
> Hi,
> I have an important Windows 2003 box which we are using only a admin
> account actively. I also need to set a password policy (i have some
> requirements) on this box and dont loose the admin account acces. How
> can i do this password policy?
>
> Regards
>

[Wim Remes-2]

Hi,

you should checkout the free benchmarks on the website of the Center  
of Information Security (http://www.cisecurity.org/). If not your  
silver bullet,
at least they are a good start.

Cheers,

Wim

On 21 Aug 2009, at 14:14, pent 5971 wrote:

> Any ideas/best practices?
>
> Regards
>
> 2009/8/20, pent 5971 <pent5971@...>:
>> Hi,
>> I have an important Windows 2003 box which we are using only a admin
>> account actively. I also need to set a password policy (i have some
>> requirements) on this box and dont loose the admin account acces. How
>> can i do this password policy?
>>
>> Regards
>>

[Gerardo Castillo Alvarado]

hi,
This can be useful:

>
>     General Recommendations for Account Lockout and Password Policy
>     Settings
>
> In addition to the specific account lockout and password policy
> settings in the previous tables, there are some other configuration
> changes that may help you achieve the level of security that you want.
> These include:
>
>     * When you enable account lockout, set the *ForceUnlockLogon*
>       registry value to 1. This setting requires that Windows
>       re-authenticates the user with a domain controller when that
>       user unlocks a computer. This helps to ensure that a user cannot
>       use a previously-cached password to unlock their computer after
>       the account is locked out.
>     * False lockouts can occur if you set the *LockoutThreshold*
>       registry value to a value that is lower than the default value
>       of 10. This is because users and programs can retry bad
>       passwords frequently enough to lock out the user account. This
>       adds to administrative costs.
>     * After you unlock an account that is locked out, verify that the
>       *LockoutDuration* value is set. You should do this because the
>       value may have changed during the account unlock process.
>     * Carefully consider setting the *LockoutDuration* registry value
>       to 0. When you apply this setting, you may incur additional
>       administrative labor by requiring administrators to manually
>       unlock a locked out user account. Although this does increase
>       security, the increased labor drawback may outweigh the security
>       benefit.
>     * Define account lockout and password policies once in every
>       domain. Ensure that these policies are defined only in the
>       default domain policy. This helps to avoid conflicting and
>       unexpected policy settings.
>     * Unlock an account from a computer that is in the same Active
>       Directory site as the account. By unlocking the account in the
>       local site, urgent replication occurs in that site which
>       triggers immediate replication of the change. Because of this,
>       the user account should be able to regain access to resources
>       faster than waiting for replication to occur. Note that the
>       AcctInfo.dll tool helps to identify an appropriate domain
>       controller and unlock the account. For more information about
>       AcctInfo.dll, see the "Account Lockout Tools" section in this
>       document.
>

check this [1]. (see "Recommended Password Policy Settings")

[1] http://technet.microsoft.com/en-us/library/cc737614(WS.10).aspx


Best regards!

pent 5971 escribió:

> Any ideas/best practices?
>
> Regards
>
> 2009/8/20, pent 5971 <pent5971@...>:
>  
>> Hi,
>> I have an important Windows 2003 box which we are using only a admin
>> account actively. I also need to set a password policy (i have some
>> requirements) on this box and dont loose the admin account acces. How
>> can i do this password policy?
>>
>> Regards
>>
>>    
>
>  

[Kevin-128]

All good points, however how this policy is enforced is problematic.
See there are only so many policy's you can place on a 2k3 domain.
Complex or not, must have 3 of the 4, upper lower, special, number and
it can't be the username.
Minimum Length, no less than X char long
Expiry, expires in X days
Previous Number, cannot be previous X number of passwords used

At my work we actually bought a piece of software called Hitachi ID
Password Manager, (formerly MTek P-Synch), we bought it for the
self-help password reset portion so users quit calling the helpdesk.
Once this is in place and the pushpass agent is installed on all domain
controllers it can control what passwords are accepted by the domain
controllers.
This has one drawback (other than money), this applies to ALL domain
passwords, much like the standard windows 2k3 password policy.
The upside is you have nearly unlimited control over what kind of
passwords are accepted on your domain, dictionary words, it'll block em,
username reversed, it'll block it. got some sneaky sysadmins using
server names as passwords, use a regular expression to block certain
password patterns, i.e. think they are using server names as passwords
(srv_MyServ1) use a regex to block anything with .srv. in it. Another
thing that I thought was helpful was that you can set a password age.
Say you have an expiry of 60 days, and the previous 6 blocked through
AD, so thats 360 months before the "first" password can be used again,
right? Nah, change your password 7 times through a windows client and
they are back to using their first password in 5 minutes. With the
password age you can say, 360 months, and they literally are blocked
from ever using that password again for 360 months.
The pushpass service checks against the hitachi server and will block
you if the password does not meet the set criteria.

I'm in no way advocating buying this software, it's just what we use and
what I have experience with, and to show you that there are products out
there (if anyone knows of an opensource product that does this, lemme
us) that can extend the bland password policies that are available in a
2k3 domain.

I'm not entirely positive, but I have "heard" that with a 2k8 domain and
vista/7 clients, you can set password policy at the OU level, with
anything prior, if it's set it cannot be overwritten by a sub policy or
by blocking the GPO applying the policy, it's a policy set at the domain
controller level, so if they get it, they abide by it, not the clients
attached to them.

And the thing with management, about being higher than director, thats
where the policy should be enforced from, not come from. It needs to
come from the security team who then send it up the line to be approved.
Management 1 step above a sysadmin or security analyst managers position
is not going to have any idea what it means to have a password policy
with X criteria, let alone director or above.
Also, with the "All passwords need to be complex (INSERT definition..)",
that's great to have on paper, but there is no way to enforce it unless
you rounded up every employee and asked them for their password, and
that won't happen. With Microsoft and 2k3 you get complex, yes or no, it
can't be defined, see above.

Rivest, Philippe wrote:

> Well first off, I would sadly say it depends a lot on your company and how
> they view security, which requirements you have (legals and business).
>
> Let's say you have a financial server (the 2k3 box) that will transfer
> customers information for credit, maybe PCI needs to be applied. You need to
> know this kind of things first.
>
> Also, maybe this server has a higher security requirement than another (you
> don’t specify). So if you're normal password policy states 6 char long for a
> password, maybe you would want to go at 8-10 for this one if its more
> critical.
>
>
> I would also make sure your local admins cant bypass the policy, maybe push
> it thru AD if you have it and they don’t have AD access? Putting it locally
> and giving them local admin is not serious enough for a critical server. So
> I would say in "Domain Policy" under admin tools in windows.
>
> Password policy should come from the top (management, higher than Director)
> and be applied to everyone and everything. It should be clear and short. 1
> page max for a password policy should be more than enough.
> -All passwords should be at least 8 character long
> -All passwords should expire after 45days
> -All passwords need to be complex (INSERT definition..)
> ...
> Have the policy signed (*approved*) by upper management and than applied to
> the 2k3 box.
>
> Side note, the sentence with "loose" I didn’t understand it too much. But I
> would also suggest limiting local admin access to a very few IT employees.
> If they don’t need it don’t give it, all this has to be approved (as we all
> know).
>
> Hope I was on your topic, if not sorry :)
>
>  
> Philippe Rivest - CEH, Network+, Server+, A+
> TransForce Inc.
> Internal auditor - Information security
> Verificateur interne - Securite de l'information
>
> 8585 Trans-Canada Highway, Suite 300
> Saint-Laurent (Quebec) H4S 1Z6
> Tel.: [phone]  
> Fax: [phone]
>
> http://www.transforce.ca/
>
>
> -----Message d'origine-----
> De : listbounce@... [mailto:listbounce@...] De
> la part de pent 5971
> Envoyé : 21 août 2009 08:14
> À : focus-ms@...
> Objet : Re: How to /password policy on Windows 2003
>
> Any ideas/best practices?
>
> Regards
>
> 2009/8/20, pent 5971 <pent5971@...>:
>  
>> Hi,
>> I have an important Windows 2003 box which we are using only a admin
>> account actively. I also need to set a password policy (i have some
>> requirements) on this box and dont loose the admin account acces. How
>> can i do this password policy?
>>
>> Regards
>>
>>    

[Kurt Dillard-3]

I've watched all of the replies flash by, I'm not sure any of them answered
the original question. Are you simply looking for directions on where to
configure the settings?

Is this Windows box part of an Active Directory domain, if it is use group
policy. If not, use the local security policy. Start > All Programs >
Administrative Tools > Local Security Policy. The precise path will vary
depend on your version of windows and how you've configured your Start Menu.
Once the tool is open expand Account Policies then click on Password Policy.
You can configure 6 password policies there. The next folder down contains
the 3 account lockout policies.

Or are you looking for advice on what values to assign to these settings? If
this is the case you already got some good advice, I would recommend
Microsoft's own guidance for Windows Server 2003:
http://go.microsoft.com/fwlink/?LinkId=14845, follow the guidelines for the
Enterprise Client (EC) scenario. Of course, I'm biased, I wrote most of that
doc :P

A note on OU-specific password policies: that is a new feature in Windows
Server 2008, I don't think the version of the clients matter, only the
domain controllers:
http://technet.microsoft.com/en-us/library/cc770394(WS.10).aspx.

Regards,

Kurt Dillard

-----Original Message-----
From: listbounce@... [mailto:listbounce@...] On
Behalf Of pent 5971
Sent: Friday, August 21, 2009 9:14 AM
To: focus-ms@...
Subject: Re: How to /password policy on Windows 2003

Any ideas/best practices?

Regards

2009/8/20, pent 5971 <pent5971@...>:
> Hi,
> I have an important Windows 2003 box which we are using only a admin
> account actively. I also need to set a password policy (i have some
> requirements) on this box and dont loose the admin account acces. How
> can i do this password policy?
>
> Regards
>

[Ben Scott-4]

On Wed, Aug 26, 2009 at 12:47 AM, Kevin <rot_betruger@...> wrote:
> Say you have an expiry of 60 days, and the previous 6 blocked
> through AD, so thats 360 months before the "first"
> password can be used again, right? Nah, change your password
> 7 times through a windows client and they are back to using their
> first password in 5 minutes.

  FWIW, that much can be countered using the "Minimum password age"
policy.  Even setting it to 1 day (the smallest possible) will usually
do the trick.

-- Ben

[Thor (Hammer of God)]

So, before I upgraded to Win7 on my production rig, I took the opportunity to try out the "Full PC Backup" for giggles just in case things went tits up.  Aside from the restore not working (it said it had a disk problem) and the fact that you can only restore to a partition the same size as the one you backed up from (it's supposed to be =>, but it didn't work out that way), I did find out some cool things about the Complete backup that you might find interesting...

First off, while you have to be admin to perform a Complete PC Backup, you no longer get the option of requiring a password to "protect" the backup.  That was cool when you were concerned with people with physical access getting to your data.  The directory created (based on HOSTNAME of unit backed up) will have local Administrators group Full, and local Backup Operators Full, but all you have to do (obviously) is pop the usb drive into a different machine that you have local admin access to and you immediately get full access.  You don't even have to change permissions... I don't consider that a big deal, and is actually easier, since if you are admin on the box, it doesn't matter what drives you put in from an OS permissions standpoint (not EFS, obviously).  

The "cool" part is that the Complete PC Backup is actually a .VHD disk file.  Sure, there is catalog information accompanying the backup, but if you need data off of the backup, you can just stick the USB source in a drive somewhere and mount the VHD to access it like a drive letter, again without worrying about file permissions.  You can do this in VPC or VMWare, or even easier, use something like WinImage to just mount the thing and grab your data.  /mosh

It would have been very cool for MSFT to have built in the functionality of actually BOOTING the vhd in VPC (or VMWare) but alas, that dog does not hunt.  While not ideal, it would require substantial driver reloading (and reactivation) anyway, but it still would be nice to be able to boot into your Complete Backup.  Just as well that you can just attach the .vhd directly in VMWare/VPC and go from there though.

That's it.. just thought I'd post up the bits about not expecting any security on your backups, and how you can now just directly mount the vhd backup file to get data without worrying about permissions.  I'm sure some with think that is a bad thing, but I've always treated backups like any other "physical access" asset, which is, if I have my hands on it, it's mine anyway (so encrypt, etc).  

Have a good one!

T

____________________
Timothy (Thor) Mullen, Ph.D.
thor@...
www.hammerofgod.com

[James D. Stallard]

Hey Thor

There's no real reason why a VHD backup should not be mountable as a VM,
after all, we all do P2V. Indeed, an automated P2V is an excellent way of
creating a warm-standby DR environment or a "real" live test bed. Mounting a
VHD as a VM would seem to be a common sense feature to me - especially as it
also raises the possibility of V2P. MS have missed a trick IMHO.

Also, we have another backup nasty on Windows 7 that also hits Windows
Server 2008 R2.

On default installations, both OSs create a 100Mb partition on the boot
drive, presumably for recovery (not bothered doing the reading on that yet).
It would seem that taking backups of the system state requires a VSS
snapshot to be created for that drive, and the drive is too small for VSS to
be happy about doing it. The result, some commercial backup software (my
test was BackupExec 12.5 SP2 fully patched) fails. You can do some VSSADMIN
jiggery-pokery to move the snapshot to another drive, but that requires a
drive letter to be assigned to the 100Mb partition and is a messy solution
at best.

Using DISKPART to setup your own partitions during installation (either OS)
does not create the 100Mb partition and so doesn't create the problem.

Kinda wandered of topic a bit, but I hope it's useful

Cheers

James

James D. Stallard MBCS CITP MIoD
Enterprise Architect
Web: www.leafgrove.com
LinkedIn: www.linkedin.com/in/jamesdstallard
Email: james@...
Mobile: [phone]
Skype: JamesDStallard

Think before you print. Please don't print this email unless you really need
to.






-----Original Message-----
From: listbounce@... [mailto:listbounce@...] On
Behalf Of Thor (Hammer of God)
Sent: 28 August 2009 20:49
To: focus-ms@...
Subject: Vista Complete PC Backup coolness

So, before I upgraded to Win7 on my production rig, I took the opportunity
to try out the "Full PC Backup" for giggles just in case things went tits
up.  Aside from the restore not working (it said it had a disk problem) and
the fact that you can only restore to a partition the same size as the one
you backed up from (it's supposed to be =>, but it didn't work out that
way), I did find out some cool things about the Complete backup that you
might find interesting...

First off, while you have to be admin to perform a Complete PC Backup, you
no longer get the option of requiring a password to "protect" the backup.
That was cool when you were concerned with people with physical access
getting to your data.  The directory created (based on HOSTNAME of unit
backed up) will have local Administrators group Full, and local Backup
Operators Full, but all you have to do (obviously) is pop the usb drive into
a different machine that you have local admin access to and you immediately
get full access.  You don't even have to change permissions... I don't
consider that a big deal, and is actually easier, since if you are admin on
the box, it doesn't matter what drives you put in from an OS permissions
standpoint (not EFS, obviously).  

The "cool" part is that the Complete PC Backup is actually a .VHD disk file.
Sure, there is catalog information accompanying the backup, but if you need
data off of the backup, you can just stick the USB source in a drive
somewhere and mount the VHD to access it like a drive letter, again without
worrying about file permissions.  You can do this in VPC or VMWare, or even
easier, use something like WinImage to just mount the thing and grab your
data.  /mosh

It would have been very cool for MSFT to have built in the functionality of
actually BOOTING the vhd in VPC (or VMWare) but alas, that dog does not
hunt.  While not ideal, it would require substantial driver reloading (and
reactivation) anyway, but it still would be nice to be able to boot into
your Complete Backup.  Just as well that you can just attach the .vhd
directly in VMWare/VPC and go from there though.

That's it.. just thought I'd post up the bits about not expecting any
security on your backups, and how you can now just directly mount the vhd
backup file to get data without worrying about permissions.  I'm sure some
with think that is a bad thing, but I've always treated backups like any
other "physical access" asset, which is, if I have my hands on it, it's mine
anyway (so encrypt, etc).  

Have a good one!

T

____________________
Timothy (Thor) Mullen, Ph.D.
thor@...
www.hammerofgod.com

[Ken Schaefer]

The 100MB partition is for Bitlocker. I am surprised that this isn't backed up normally/transparently as part of a backup that includes system state...

Cheers
Ken

-----Original Message-----
From: listbounce@... [mailto:listbounce@...] On Behalf Of James D. Stallard
Sent: Thursday, 3 September 2009 6:50 AM
To: 'Thor (Hammer of God)'; focus-ms@...
Subject: RE: Vista Complete PC Backup coolness

Hey Thor

There's no real reason why a VHD backup should not be mountable as a VM, after all, we all do P2V. Indeed, an automated P2V is an excellent way of creating a warm-standby DR environment or a "real" live test bed. Mounting a VHD as a VM would seem to be a common sense feature to me - especially as it also raises the possibility of V2P. MS have missed a trick IMHO.

Also, we have another backup nasty on Windows 7 that also hits Windows Server 2008 R2.

On default installations, both OSs create a 100Mb partition on the boot drive, presumably for recovery (not bothered doing the reading on that yet).
It would seem that taking backups of the system state requires a VSS snapshot to be created for that drive, and the drive is too small for VSS to be happy about doing it. The result, some commercial backup software (my test was BackupExec 12.5 SP2 fully patched) fails. You can do some VSSADMIN jiggery-pokery to move the snapshot to another drive, but that requires a drive letter to be assigned to the 100Mb partition and is a messy solution at best.

Using DISKPART to setup your own partitions during installation (either OS) does not create the 100Mb partition and so doesn't create the problem.

Kinda wandered of topic a bit, but I hope it's useful

Cheers

James

James D. Stallard MBCS CITP MIoD
Enterprise Architect
Web: www.leafgrove.com
LinkedIn: www.linkedin.com/in/jamesdstallard
Email: james@...
Mobile: [phone]
Skype: JamesDStallard

Think before you print. Please don't print this email unless you really need to.






-----Original Message-----
From: listbounce@... [mailto:listbounce@...] On Behalf Of Thor (Hammer of God)
Sent: 28 August 2009 20:49
To: focus-ms@...
Subject: Vista Complete PC Backup coolness

So, before I upgraded to Win7 on my production rig, I took the opportunity to try out the "Full PC Backup" for giggles just in case things went tits up.  Aside from the restore not working (it said it had a disk problem) and the fact that you can only restore to a partition the same size as the one you backed up from (it's supposed to be =>, but it didn't work out that way), I did find out some cool things about the Complete backup that you might find interesting...

First off, while you have to be admin to perform a Complete PC Backup, you no longer get the option of requiring a password to "protect" the backup.
That was cool when you were concerned with people with physical access getting to your data.  The directory created (based on HOSTNAME of unit backed up) will have local Administrators group Full, and local Backup Operators Full, but all you have to do (obviously) is pop the usb drive into a different machine that you have local admin access to and you immediately get full access.  You don't even have to change permissions... I don't consider that a big deal, and is actually easier, since if you are admin on the box, it doesn't matter what drives you put in from an OS permissions standpoint (not EFS, obviously).  

The "cool" part is that the Complete PC Backup is actually a .VHD disk file.
Sure, there is catalog information accompanying the backup, but if you need data off of the backup, you can just stick the USB source in a drive somewhere and mount the VHD to access it like a drive letter, again without worrying about file permissions.  You can do this in VPC or VMWare, or even easier, use something like WinImage to just mount the thing and grab your data.  /mosh

It would have been very cool for MSFT to have built in the functionality of actually BOOTING the vhd in VPC (or VMWare) but alas, that dog does not hunt.  While not ideal, it would require substantial driver reloading (and
reactivation) anyway, but it still would be nice to be able to boot into your Complete Backup.  Just as well that you can just attach the .vhd directly in VMWare/VPC and go from there though.

That's it.. just thought I'd post up the bits about not expecting any security on your backups, and how you can now just directly mount the vhd backup file to get data without worrying about permissions.  I'm sure some with think that is a bad thing, but I've always treated backups like any other "physical access" asset, which is, if I have my hands on it, it's mine anyway (so encrypt, etc).  

Have a good one!

T

____________________
Timothy (Thor) Mullen, Ph.D.
thor@...
www.hammerofgod.com