If you would like to read the other parts in this article series please go to:
- Active Directory Insights (Part 1) – Configuring DNS on domain controllers
- Active Directory Insights (Part 2) – Digging into trusts
- Active Directory Insights (Part 3) – Re-examining read-only domain controllers
- Active Directory Insights (Part 4) – More about read-only domain controllers
- Active Directory Insights (Part 5) – Domain controller hardware sizing
- Active Directory Insights (Part 6) – Domain controllers and NIC teaming
- Active Directory Insights (Part 7) – Virtual domain controllers and disaster recovery
- Active Directory Insights (Part 8) – More on using virtual domain controllers
- Active Directory Insights (Part 9) – Automating user account provisioning
- Active Directory Insights (Part 10) – DHCP and domain controllers
- Active Directory Insights (Part 11) – sIDHistory
- Active Directory Insights (Part 12) – MaxTokenSize
- Active Directory Insights (Part 13) – Digging into the Global Catalog
- Active Directory Insights (Part 14) – More about the Global Catalog
- Active Directory Insights (Part 15) – Investigating locked out accounts
Many administrators of Active Directory environments make use of account lockout policies to help safeguard their directory information from malicious users. However, policies are of now use unless they are regularly reported upon and examined to evaluate their effectiveness and determine whether any unanticipated problems are occurring.
Having secondary admin accounts for your Active Directory administrators and implementing a secondary password policy using the fine grain password policy feature of Active Directory are both effective ways of helping to safeguard the integrity of your organization’s directory services. To help us understand this subject better, I’ve once again asked Andrew Perchaluk, a Senior Systems Administrator at the University of Manitoba in Winnipeg, Canada to provide us with some insight and tips from his own experience managing Active Directory environments. Andrew is a husband, father, and dog lover who has been working in the Information Technology industry for almost 20 years and who enjoys sharing his experiences with others in the IT pro community. For more information about Andrew see his LinkedIn profile. You can also follow him on Twitter.
Let’s now hear what Andrew has to say on this topic…
Active directory password policies and why you should consider more than one
Do me a favor and ask yourself the following questions:
1. How often do you and other system administrators in your organization change your passwords? Every 3 months, 6 months, a year……never
2. How strong is your password?
3. Is the account you login to your desktop every day and use a “privileged” account?
a. Does this account have permissions to manage servers, File shares, Exchange systems, Databases?
b. Is this account email enabled?
4. Does this account have local Administrator access to your computer?
I asked myself similar questions a while back and didn’t like all of my answers. If you find yourself not liking your answers (or are having to defend your answers in your head) maybe it’s time to make some changes. You could be leaving your data and systems vulnerable, one of these vulnerabilities that many companies know all too well is ransomware, which is defined as:
“A type of malicious software designed to block access to a computer system until a sum of money is paid.”
How can you lower the risk of a similar incident occurring within your environment?
The targets of ransomware have been growing the “bad guys” like to go after financial institutions, hospitals, government offices and educational institutions like universities and colleges.
Recently, the University of Calgary was victim to a ransomware incident that impacted many of their IT services including email and file shares. The majority of their users were without email and without access to key systems for several days, resulting in significant financial and productivity impacts. The suspected cause of that incident was the result of the misuse of a privileged account. It’s been reported they paid $20,000 in ransom to decrypt their files:
http://www.cbc.ca/news/canada/calgary/university-calgary-ransomware-cyberattack-1.3620979
Just a couple days ago Carleton University was hit by a similar ransomware attack reportedly demanding $38,000 in ransom to decrypt their data, they are still dealing with this and it will likely take weeks to fully recover:
How can you lower the risk of a similar incident occurring within your environment?
These are just a few things that can help, this article’s main focus is on the first two points below:
1. Use a separate AD account for work which requires elevated permissions, such as Active Directory administration and management of dependent services such as File Shares, SCCM, MSSQL databases, and server access.
2. Set a strong, secure password on these secondary accounts and use a secondary domain password policy to enforce.
3. Don’t allow users attached to your domain to have local Administrator access on their workstations and especially System Administrators.
4. Keep your Antivirus up to date on desktops and servers and be sure you have reliable backups that you can use to restore data in the “worst case” scenario that live data has become encrypted.
Why should I use a second AD account for elevated IT administration access?
If you’ve had the pleasure of dealing with Auditors this will keep them happy, but that’s not the most important reason. The best reasons are that malware, viruses and ransomware almost always get into our organization from an email (attachment or link) or a malicious website or download, then if the user has elevated access on their computer and they trigger a malicious payload it spreads to anything and everything it can. This is almost certainly what happened in the examples mentioned earlier, likely a System Administrator was logged in with their AD account (like they did everyday) which they used for email, web browsing, accessing files, printing, etc. The only catch was this same account also had elevated permissions (ie: Domain Admins, Exchange Admin, Full access to Network shares), and when this user accidently clicked something malicious the ransomware spread to not only their local computer but to entire email databases, and network file shares.
20,000 dollars later….
Don’t let this happen to you, I’ve implemented this as a proactive measure and would recommend others do something similar:
• Create individual secondary accounts for systems administrators
• Never email enable this account
• Assign any elevated access groups and permissions such as Domain admins, Exchange Organization management, etc. to this new account
• Only use these accounts for IT administrative tasks
- Active Directory administration
- File Share management
- SCCM management
- MSSQL database management
- Server access
• Avoid using for web browsing and opening attachments
• Assign a strong password to this account
• Remove all elevated access groups from these users original accounts
• Use this original account for email, web browsing, documentation, etc.
• You don’t need to login to your laptop or a desktop with a domain admin account
• System administrators — if you haven’t already remove your original account from the local administrator groups on your desktops.
Why do I need a secondary password policy?
You must be running Active Directory 2008 or higher to implement secondary password policies. The benefits are that you can create a much stronger password policy and apply it to accounts with greater permissions and access (ie: Domain Admins, accounts with access to financial systems, etc.) without affecting the default domain password policy. This is useful because these privileged accounts are typically a smaller subset of your overall Active Directory user base, and may have different password requirements. For example you may want the privileged accounts in your AD to require a password reset every 90 days while for typical AD user’s passwords that expire every 6 months is acceptable.
How can I setup a secondary fine grain password policy?
1) Use Active Directory Administrative Center (ADAC) on a Server 2012 R2 system.
2) Switch to the Tree View and navigate to the System, Password Settings Container.
3) Right-click the Password Settings Container object and select “New”, “Password Settings”
4) In the “Create Password Policy” UI, fill all the fields that are appropriate:
5) Click the add button in the “Directly Applies To” section and select the Global Group(s) you want to target. In my case I applied it to the Domain Admins and a 2nd group that we placed our “elevated permissions” accounts in.
How to check if a user is getting the password policy
1) From a command line run:
Dsget user "CN=Andrew Perchaluk,CN=Users,DC=adlab,DC=test" --effectivepso
2) You should get back something similar to
Effectivepso "CN=Secure Password policy,CN=Password settings container,CN=System,DC=adlab,DC=test" Dsget succeeded
3) Or look at attribute editor and msDS-ResultantPSO value if it says “Not set” then the domain password policy is in effect:
When are passwords enforced, how will it impact the user?
Once the policy is written and replicated (Fine Grain Password Policy or Domain policy) the following will take effect and can impact a user immediately:
• Minimum password age
• Maximum password age
• Lockout duration
• Lockout threshold
• Observation window
Other settings also in effect, however users are not affected until a password change:
• Minimum password length
• Password must meet complexity requirements
• Reversible encryption
Still got questions about Active Directory?
If you have any questions about domain controller hardware planning, the best place to ask them is the Active Directory Domain Services forum on TechNet. If you don’t get help that you need there, you can try sending your question to [email protected] so we can publish it in the Ask Our Readers section of our newsletter and see whether any of the almost 100,000 IT pro subscribers of our newsletter have any suggestions concerning your problem.
