12:56 PM
Dan Tesch
Dan Tesch

Centralized Authentication: A Double-Edged Sword

Active Directory is a great centralized authentication service for security and compliance, but Macs, mobile devices, and remote access cause headaches.

When I arrived at my current employer about seven years ago, I was surprised to find no Active Directory. There was an attempt at an LDAP infrastructure, but the only thing authenticating to it was a single Samba server.

The replication to a secondary LDAP server was broken, email was off on its own, wireless was a collection of consumer-grade access points using static WAP keys, and every application -- whether commercial or internally developed -- had its own authentication scheme. I don't want to say it was a mess, but there was little evidence of a consistent authentication strategy or direction.

["Threat intelligence" is the latest must-have thing. Read Why Threat Intelligence Is Like Teenage Sex.]

One of my first projects was to migrate from a legacy email system to Exchange. Since Exchange requires Active Directory, I saw an opportunity to begin to centralize authentication. Over time, new Windows servers were all put into Active Directory, a new multi-site distributed file server system was installed, and I talked with our developers about pointing applications requiring authentication to Active Directory. Next came a new wireless system and updated VPN endpoints; these, too, via Microsoft's version of a Radius server, tied into Active Directory.

My goal wasn't to have absolutely everything authenticate to Active Directory, but in my view, more is better. In theory, it should be easier for end users, because they have to remember only one set of credentials, and changing a password once takes care of many services. From an administrative perspective, Active Directory gives you one place to deactivate an account that covers multiple points of entry; I even configured our entire router, switch, and firewall infrastructure to authenticate administrative access against Active Directory.

As our IT operations evolved and security policies and compliance needs grew, we began to implement password change and account lockout policies. These policies help us protect critical infrastructure and information.

Mac, mobile, remote access headaches
All in all, I consider this implementation a success. However, it doesn't mean there aren't difficulties. First on the list is Macintosh users, who make up about a third of our computing population. Macs can be joined to Active Directory, but they aren't fully fledged members, so you can forget about simple group policies such as locking screen savers.

In addition, Macs on their own don't have a mechanism to inform users about expiring passwords, and changing an Active Directory password from within the Mac OS isn't a reliable solution. I haven't been able to get it to work at all, even with add-on products such as Centrify. Also, logins from Macs to wireless networks and file servers are not unified like they are in Windows.

Macs are a hassle, but the majority of problems came from mobile devices. As more people configured phones and tablets to access their email and connect to our wireless network, account lockouts increased exponentially. Why? When people change their password, they forget about all of the places

Next Page

it is used and saved. In the case of a mobile phone, someone will likely remember to change their email password but often forgets that the saved wireless password needs to change, as well.

If users don't connect to the wireless network at the office for a while and their password changes, the next time they do try to connect, the device issues the old password. Active Directory interprets the password as incorrect and locks out the users.

Tablets are commonly shared among designers and people doing user interface testing. If the tablet connects to the network, nobody stops to think about whose credential it's using -- until the person who last entered his username and password changes it. Then a forgotten device ends up locking an unsuspecting user's account.

Saving passwords in browsers, the Mac Keychain, and Windows Credential Manager, while convenient, complicates centralized authentication. Sometimes it takes days to discover where the bad password is stored. One person left his email account configured on his iPad and gave it to his father, who lived overseas. Lockouts occurred only when his father connected the iPad to the Internet; it took us literally months to discover what was going on.

Remote users have also had difficulties. For instance, someone might change a password via our webmail system and then turn around and attempt to authenticate to a VPN endpoint. If the endpoint is at a different data center that hasn't received the updated password via Active Directory replication, the user gets locked out.

I've tried a few things to improve the situation. We modified Active Directory replication settings to make them quicker. We also evaluated a variety of Active Directory reporting tools and put some into use.

For example, Lockout Status from Microsoft is simple, free, and helpful. It's a standalone .exe that requires no installation and allows for a quick view into which Domain Controller is getting bad password attempts. This speeds troubleshooting by reducing the amount of time it takes to determine where lockouts are occurring.

Centralized authentication can cause significant headaches for users and administrators alike. Even the most tech-savvy and self-sufficient people can occasionally be stymied. But user education can go a long way toward minimizing these problems. I don't plan to retreat from the policies and procedures we have in place, because they help protect the organization.

Cyber-criminals wielding advanced persistent threats have plenty of innovative techniques to evade network and endpoint defenses. It's scary stuff, and ignorance is definitely not bliss. How to fight back? Think security that's distributed, stratified, and adaptive. Read our Advanced Attacks Demand New Defenses report today (free registration required).

Dan Tesch is an IT Director at a Chicago-area marketing firm. He's also a member of the Interop Advisory Board. Dan's technology experience began in the late 1980s in the publishing industry, and now includes networking, virtualization, storage and security. View Full Bio

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Comment  | 
Email This  | 
Print  | 
More Insights
Copyright © 2021 UBM Electronics, A UBM company, All rights reserved. Privacy Policy | Terms of Service