Tag Archives: directory

Homelab – 2012 to 2019 AD upgrade

I foolishly thought that I would quickly swap out my 2012 domain controllers with 2019 domain controllers, thus beginning a weeks-long saga. I have 2 DCs in my homelab, DC1 and DC2.

Built a new DC, joined to the domain, promoted to a DC (it ran AD prep for me, nice!), transferred FSMO roles (all were on DC1), all looked great! Demoted DC1, all logins failed with ‘Domain Unavailable’.


Thankfully I had my Synology backing up my FSMO role holder DC. So I restored it from scratch. I figured I might have missed something obvious so I did it again. Same result.

Ran through all sorts of crazy debugging, ntdsutil commands looking for old metadata to clean up, found some old artifacts that I thought might have been causing the issue, and repeated the process. Same result.

Several weeks later I realized what happened – I had a failing UPS take down my Synology multiple times until I replaced it a few days ago. Guess which VM I never restarted? The Enterprise CA. The CA caused all of this. Or at least most of it. Even after I powered up the CA, I was unable to cleanly transfer all FSMO roles. Everything but the Schema Master transferred cleanly, even though they all transferred cleanly while the CA was down. I had to seize the schema master role and manually delete DC1 from ADUC – thankfully, current versions of AD do the metadata cleanup for you when you delete a DC from ADUC.

In hilarious irony, I specifically built the CA on a member server and not a domain controller to avoid upgrade problems.

In summary:

  1. When you don’t administer AD every day, you forget lots of things
  2. No AD upgrade is easy
  3. Make sure you have a domain controller backup before you start
  4. Turn on your CA
  5. Run repadmin /showrepl and dcdiag BEFORE you start messing with the domain
  6. Run repadmin /showrepl and dcdiag AFTER you add a domain controller and BEFORE you remove old domain controllers
  7. ntdsutil is like COBOL – old and verbose

Google Apps – Active Directory Sync

We do a lot of education sector consulting and questions on Google Apps invariably pop up. The pricetag (free for education) is obviously attractive. Running a mail server in-house can be an endless time sink, so it’s not a bad idea to outsource it to Google. They deal with the spammers and storage, all you have to do is provision the accounts. Choosing how to provision is a critical decision for a Google deployment. One of the biggest sources of confusion that I see is directory integration with Google Apps. Most schools already have an existing directory, typically AD or Novell eDirectory. The school admins are interested in getting Google to autoprovision accounts and how to manage user passwords.

Google has a provisioning tool called Google Apps Directory Sync (GADS) used to sync your LDAP directory with Google Apps. GADS runs as a scheduled task on a Windows server inside the client network. The program collects data from an LDAP server, then syncs the results to the Google Apps. I’ve done this with Novell too, but most of my experience is with AD, so I am writing this article from that perspective.

There are many ways to handle the sync of both users and passwords. None of the methods are perfect; as with most things in IT, you have to balance convenience with security.

  1. Sync your AD accounts and passwords directly into Google Apps
  2. You can sync your existing AD accounts and passwords into Google. However, to make that happen you have to jump through Active Directory hoops and store your user passwords in an additional attribute on the user object. There is sample code out there showing you how to intercept password changes on domain controllers, then save them in another format that GADS can read. The passwords has to be either SHA-1, MD5, or plaintext. SHA-1 and MD5 are no longer secure encryption protocols.

    I’m not a big fan of any of this. I don’t want to downgrade the security of my Windows network by using a poorly secured password attribute. Even worse, this method means all of your AD credentials, some of which will be privileged and some of which have VPN access, are floating around in the Google cloud.

  3. Sync your AD accounts with a one-time password
  4. You can sync your existing AD accounts into Google and use another directory attribute to set a one-time password. You might key on EmployeeID or StudentID or something similar. The user uses that password for first login, then changes their password on login. After the initial password is set, the AD password is not connected to the Google password at all. You use the Google password to access Google’s services whether you’re using a web browser or mobile phone. AD password changes have no effect on the Google password.

  5. Use Single Sign-on
  6. This is arguably the most secure, but also the most complex to set up. This requires setting up an IIS server with a public IP and SSL certificate, and installation of Microsoft’s ADFS 2.0 services (there are other ADFS providers, but this is free). This server is hosted on the customer’s network. The nice thing about this is that all authentication happens on your own ADFS server – Google doesn’t have a copy of your AD passwords. Your SAML server is trusted by Google via the use of certificates. The servers pass authentication tokens without actually transmitting passwords. Google offers a detailed diagram of what happens during a SAML exchange.

    The problem here is that you still have a Google password. ADFS only comes into play when checking your GMail via web browser – you still need a Google password to connect from your mobile device using the GMail app. So you still have to manage Google passwords and your users can get confused.

In the end, I think the SSO solution is the best for education. I don’t see much of a need for students to access their school GMail account with their cellphones. Some of the more tech-oriented teachers will want that feature, but you can do it on an as-requested basis. For the most part, you’re providing Google passwords to a subset of your administrative staff. This is a perfectly manageable number of mobile devices to support for the vast majority of districts that I’ve been involved with.