Kurt

Quick hello to all and a Happy Holidays. Some good qustions and reads on this forum so thought I would sign up. My background is with Active Directory / Exchange architecture and configuration. Pleased to be here. I've posted some responses in the various Usenet sections here but they don't show up. Is there some sort of additional verfication required to have posts submit and display? Happy Holidays- Kurt L. Senior Support Lead / MCSE / CCNP SysOp Tools www.sysoptools.com

Quick hello to all and a Happy Holidays. Some good qustions and reads on this forum so thought I would sign up. My background is with Active Directory / Exchange architecture and configuration. Pleased to be here. I've posted some responses in the various Usenet sections here but they don't show up. Is there some sort of additional verfication required to have posts submit and display? Happy Holidays- Kurt L. Senior Support Lead / MCSE / CCNP SysOp Tools www.sysoptools.com

You know... I have an admin friend of mine who works for a large company (14000 users worldwide), and they actually do this! All passwords are kept in an Access database. The admin changes passwords for the users as needed and then calls them to give them their new password. Everyone thinks it is totally insane, and due to the manual nature of this system the user's passwords seldom get changed. Executives will not buy in to enabling a domain password change policy which is really the way to go. So they are stuck with this method for now, which I think was carried over from when they were running an NT4 / Novell environment. (they are running 2003 native now). I really do not recommend this approach- It is actually a lot more work than it's worth (i've witnessed it first-hand), and would be considered a security risk by any compliance standard. Happy Holidays- Kurt L. Senior Support Lead / MCSE / CCNP SysOp Tools http://www.sysoptools.com

Anteaus- Yes, it can be quite confusing and there are not a lot of good sources that clearly explain the Active Directoy password policy and settings. Please read this white paper from Microsoft, which is probably the BEST ever on explaining the password policy settings and giving you some clear initial settings to work with. http://www.sysoptools.com/support.html#wp Download document #1, go to page 9 to view the table of recommended settings. If you fully read this document, you will completely understand how the policies function. You may also wish to read document #5 which coveres how the policy functions in Active Directory and why you must define your password change policy settings in the default policy for the domain. Happy Holidays- Kurt L. Senior Support Lead / MCSE / CCNP SysOp Tools http://www.sysoptools.com

We totally understand this problem and have created a specific utility that resolves the notification issue to users. It's also extremely easy to set up and use, and does not require any VB, LDAP or scripting knowledge. http://www.sysoptools.com Happy Holidays- Kurt L. Senior Support Lead / MCSE / CCNP SysOp Tools http://www.sysoptools.com

It is highly advised to enable password changes in your domain environment for user accounts vs. maintaining static passwords. Sure, your users will grumble a bit having to pick new passwords and there is potential for "sticky notes"... However, at least any found sticky note passwords will not be valid for more than xx days per your password change policy. If deployed correctly and with the proper support tools in place, rolling out a password change policy in an existing domain won't be as challenging as you think and will certainly improve your internal security. Here are some suggestions for helping with your initiative: 1. Get senior management / exectuve buy-in before planning a password change environment. It's imperative that senior managers and/or executive staff are 100% on board with implementing a password change policy. Having support from the top makes implementing your change policy that much easier- Find out what password change term would be comfortable for them, 60 days, 90 days, etc... If you are working to meet PCI, HIPAA, GLB or SOX-related goals surrounding user account security you'll probably need to stick to 60 days at most. If you are fortunate enough to not have to worry about compliance then the maximum age of user passwords is pretty much an internal desicion. You could start at say, 120 days and eventually shorten the policy to 60 days over the course of a year, after users become familiar with the change process. 2. Communicate to users before and during deployment. This is important and often overlooked by IT. Before you roll out your password change policy, communicate openly to users about the upcoming password change policy via email and/or company meetings. Set expectations accordingly, answer questions, and generally explain to users why the policy is being implemented and how their part in the process will help ensure security of internal company assets. Users like to feel included, especially on things that will change the way they use company systems. Remember, you can't please everyone but even the grumblers will appreciate being informed. 3. Gain knowledge about how to properly implement a password change policy in an existing domain. If your password change policy is enabled without proper pre-planning, you're going to have a lot of upset users with expired passwords. Read our planning whitepaper which discusses a couple of password change deployment methods that will keep impact to your users at a minimum: http://www.sysoptools.com/support.html#wp You'll want to read #2. Also read #1 and #5 which discuss the password policy settings, best practice / suggested settings, and how the password policy functions in Active Directory. 4. Use a good support tool to plan and support your password change deployment. Our software tool Password Reminder PRO is designed to automatically alert and remind users of upcoming password expirations in a reliable and friendly manner. You can choose when to have reminder sent to users in advance of password expiration, customize the reminder message and include instructions / support contact info / links to help docs / example of a proper password, etc. In addition, you'll receive a daily report summary of users who'se password will expire soon, expired password accounts, potential problem accounts, etc. You can use the built in Report Console to easily review all of your domain user accounts by "type" and identify possible account problems before deploying your domain change password policy. Password Reminder PRO makes deploying and maintaining an internal change password policy significantly easier for both the end user and IT staff, and will help keep support calls surrounding expired passwords to a minimum, especially if you have a number of laptop, Outlook Web Access and VPN users. Password Reminder PRO is totally free to use for two months, so try it out as part of your pre-deployment planning and see if you find value in using it. 5. Resign to the fact that the first two to three password change intervals will be the toughest on your user community and support staff. This is the "adjustment period" as users become accustomed to creating a new password every xx days. If you plan and implement your password change deployment properly, communicate effectively to users about the upcoming change, and set their expectations accordingly, you'll end up with a much easier job on your hands. While definitely not required, our Password Reminder PRO tool is specifically designed to ease the burden of deploying and maintaining a password change policy, and ensure success. Happy Holidays and good luck whichever direction you decide- Kurt L. Senior Support Lead / MCSE / CCNP SysOp Tools http://www.sysoptools.com