In this blog we successfully set up a replication between our two ACS servers. We can think about this as a completed installation. We have now ability to add network clients and users and to do AAA – Authentication/Authorization/Accounting using both RADIUS and TACACS+ protocols. Nice! But…
We might want to leverage the fact that we have already a user database in place, such as an “Active Directory” from Microsoft, an “LDAP” from some other vendor, or “RSA SecurID” from EMC. Even some other RADIUS is possible. Why not use these databases? One thing our users hate most are passwords! They can hardly cope with only domain password, and now we ask them to remember one more from ACS. Did you have a chance to see monitors with stickers on them containing passwords? Me? I had seen passwords written on a monitor itself with a pen!!!
So, the decision is made for us and we have to integrate our ACS system to “Windows Active Directory” domain in order to use usernames and passwords stored there. Piece of cake? Read on…
In version 4.x of ACS we would install our ACS as a windows application on a windows server which is joined to AD domain. It was very easy to do a group mapping and use AD credentials for authentication. Well, what has changed? Not much. The ACS still has to be a part of AD domain in order to query it for credentials, but now ACS 5.x is a Linux. Linux box or virtual appliance, it does not matter. And what does not go hand in hand with Linux? Windows! Ok, we can argue on this, but Linux uses SAMBA to talk to Windows AD and this sometimes can cause us hard time…
Before we even try this process, there are some strict rules we have to comply to:
- The ACS have to have a NTP server set up; ok this is normal
- All of domain controllers should use the very same NTP server; well, unusual, but ok
- All DCs have to be in-sync and replication should work; ok
- The time zone on ACS and DCs has to be the same; ok as well
- The time zones must have the same name; WTH?
- The forest and domain functional levels should be at least Windows 2003; well …
- The username we use for joining must have appropriate permission on AD; ok
Let me say that some of these requirements are found in Cisco’s documentation and some on different forums, Cisco’s among them. While some of them are perfectly ok, such as user having appropriate credentials, say, being a member of “Domain Admins” group; others are, well, strange. Why would we need to adjust our time from the same time source for both ACS and DCs, as long as times are in-sync? And if my time zone name on DCs is “GMT+1” and on ACS “Europe/Belgrade”, why would this be an issue? In fact, this is exactly my case and I did manage to join the ACS to the domain, but Cisco’s example stated just that.
Now don’t get me wrong, I’m not saying this product is bad, I like Cisco’s products, but I’m getting a feeling that they are making things more and more complicated and as such more prone to problems and issues.
I know that many had issues with joining the ACS to a domain, and here is my story…
First go to “Users and Identity Stores”, select “Active Directory”, and you will see this screen:
I have one primary and one secondary instance. I have my Windows AD credentials. The user name I’m going to use is member of “Domain Admins” groups, and as such has appropriate rights to create/delete computers and some more permissions. Perhaps I should use here a principal of least privilege, but hey, I have already had my share of pain with this
Now I selected my primary instance and click “Join/Test Connection”. I then filled in appropriate fields and clicked “Test Connection”:
The result promised:
But wait, now SAMBA/SMB combination kicks in. If all tests are ok, why would join be a problem. Let’s click join and see:
Before we see results, let me stress one more time that all requirements are fulfilled!
WTH? For the Internet search engines to catch this, it says: “Failed During Join [Error while configuring Active Directory: Using writable domain controller: dc03.popravak.com (kerberos) Authentication error due to unexpected configuration or network error. Please try the –verbose option or run ‘adinfo –diag’ to diagnose the problem. Join to domain ‘popravak.com’, zone ‘null’ failed.]”
This is very nice, especially having in mind the fact that in the lab when I was trying this, all went as smooth as it could. But what now? Back to the laboratory…
I checked, double checked, triple checked everything: times, time zones, credentials, DCs, AD replication, … No luck. Time goes by…
I have noticed that after this failed process, there were no computer account created within the AD. So, I created one, called “ACS51”, like the name of my primary ACS server. I stated that “Domain Admins” had the right to join this machine to the domain and username I was using was a member of that group. This is a snap shot from “Active Directory Users And Computers” :
Then I tried again – the same error. After some more investigation I was heading nowhere! I had already lost to much time on this, so I contacted Cisco TAC. I must say that they had some tough time figuring this out! After a “Webex” session, many mails, debugs, captures, after several days they suggested resetting the ACS51 Active Directory computer account. Who would though of that??? Ok, let’s try. Again, this is from the “Active Directory Users and Computers”:
After resetting this account I repeated the whole process and guess what? ACS51 was successful joining the domain!
Now I tried the exact process with the secondary instance and all happened to the letter as for the primary! Now I have the desired status:
The status for both instances is as should be “Joined and Connected”.
Yes, I’m happy! I did loose lots of time, but I’m happy. But I’m concerned as well: will I have authentication issues that will be as hard to diagnose as the joining itself? Hope not.
Ok, there you go. I hope this experience will cut the lost time somebody loses at least in half. If so, then my suffer would have some sense
Thanks for reading!