Frustrating Beginnings
When I started my first day at FrogSlayer, I was given access to the various IT systems. Separate accounts were created in Active Directory, Dropbox, Google, Azure, and AWS (which had two different portals). I made a note of where each service was at and what it did. Permissions for users varied between services and removing user access required a list of steps in order to make sure something didn’t get missed. In addition to this our version control software was hosted in the cloud and authenticating off of the Domain Controller (DC) in the office. This resulted in frustrating delays while the developers were coding.
Initial Research
The first idea was to implement a DC in the cloud replicated to the physical DC in the office to resolve the version control speed issues. But before jumping in to make changes we decided to stop and evaluate our options. The first step was to identify requirements. When boiling it all down the main requirement was a fast and reliable system which allowed a single username and password to access all company applications. This would provide security through the ability to memorize a single username and password instead of needing sticky notes to remember multiple credentials. Also a single source for authentication would ease the on-boarding process, ongoing permission management as well as the need to remove permissions when an employee moves on.
Possible Options
Understanding the basic requirements, we looked at features and experimented around with a number of options including Bitium, Onelogin, Okta, Azure Active Directory and a few open source solutions. As we compared cost, functionality and requirements we decided to give Azure AD a try.
Jumping In
Implementation started by setting up Azure AD Connect to synchronize with our local DC. Next, Azure AD Domain Services was configured to enable LDAP and the ability to join servers to Azure AD. Following this, site to site VPNs were setup and we configured a couple of applications to put some live traffic onto the system. We kept things this way for a while as we worked out bugs in the system and verified that it was stable. Over the next month we moved the rest of the applications over. Following this, Windows servers were joined to Azure AD and desktops configured to login with Azure AD credentials. Finally we retired the local DC.
Solution Pros
- Single source of authentication
- Two factor authentication is required for password changes and logins from new machines.
- We were able to configure Single Sign On for AWS, Azure, Google Apps, and WordPress. Other applications use LDAP or Windows integrated authentication.
- Many third party apps are in the Gallery. We were able to setup a connection to our DNS provider’s web interface so users do not need a password for access.
- Groups can be used to grant access to specific services.
- Users can change their password from a web interface.
Solution Cons
- Azure AD does not support GPOs.
- There is a bit of lag from when changes are made in Azure AD and when they are pushed to Azure AD Domain Services (usually only 15-30 minutes).
- You cannot change a number of the user attributes in LDAP. Email is one example, but if you create an exchange online mailbox it will populate the field for you.
- Joining servers and PCs to the “new” domain invokes a need to re-create local profiles.
- When changing domains, SQL server loses all domain user permissions, make sure you have the SA password.
Finished Product
We now have all of our apps authenticating off of a single solution. A dashboard with links to all internal applications is the starting place for new hires and a quick reference for existing employees. Our version control software is fast and both the users and IT are happy. With all of the current breaches in security happening, have you stopped to consider whether your current authentication systems are easy for your users to use and actually keeping you secure?
