ACS 5.2 Joining Multi-DC Domain

jason.yates · ‎12-21-2010

Hi,

Thanks for taking the time to read my question.

I've just installed two ACS 5.2 appliances and I'm trying to get them to join my domain, I've setup an account that has the relevant permissions (tested the account on a laptop and it can join the machine to the domain).

The ACS keeps coming back with an invalid credentials to join the domain error despite the fact that I know the user in question has the correct permissions.

I have a suspicion that the problem is related to how the ACS handles the Active Directory Domain, we have a large domain that spans several domain controllers. The DNS server uses round robin DNS to serve a different DC's IP each time, however a typical windows laptop is aware of what controllers it's allowed to use whereas the ACS box doesn't appear to be.

The ACS servers are located in a network in the UK that is only allowed to talk to 2/6 DC's and I have no way of controlling what IP appears when the ACS tries to join the domain due to the round robin DNS.

Is there any way to get around this? Or any way to hard code a specific DC for the server to connect to? Even being able to add the DNS manually to a hosts file would help.

Thanks

jason.yates · ‎12-21-2010

Also, I have the following output in the logs:

Dec 21 15:13:06 acsserver01 adinfo[7388]: INFO base.bind.ad ConnectToServer: fetch("") from xxx01.domain.local:389 failed (Reason: fetch :

Can't contact LDAP server)

Dec 21 15:13:11 acsserver01 adinfo[7388]: WARN base.kerberos.keytab getUserSalt failed: get creds: Client not found in Kerberos database

Dec 21 15:13:16 acsserver01 adinfo[7388]: INFO base.bind.ad ConnectToServer: fetch("") from xxx02.domain.local:389 failed (Reason: fetch :

Can't contact LDAP server)

Dec 21 15:13:21 acsserver01 adinfo[7388]: WARN base.kerberos.keytab getUserSalt failed: get creds: Client not found in Kerberos database

Dec 21 15:13:26 acsserver01 adinfo[7388]: INFO base.bind.ad ConnectToServer: fetch("") from xxx03.domain.local:389 failed (Reason: fetch :

Can't contact LDAP server)

Dec 21 15:13:31 acsserver01 adinfo[7388]: INFO base.bind.ad Reached adclient.server.try.max before finding a valid server

It looks like the ACS is giving up before it gets to a DC that it has the ability to join. Is there any way to

a) Force a specific DC / selection of DC's

b) Edit hosts file to specify a single DC

Tiago Antunes · ‎12-28-2010

Hi,

I think this is what you are facing:

CSCte92062 - ACS should be able to query only desired DCs

You will need to allow the ACS to reach all DCs or make sure DNS only returns the DCs the ACS can reach.

Also, the user you are using to join the domain must be able to authenticate to the entire domain (on all DCs).

HTH,

Tiago

--

If this helps you and/or answers your question please mark the question as "answered" and/or rate it, so other users can easily find it.

jason.yates · ‎12-29-2010

Thanks for your reply however simply saying "Make sure the ACS can reach all DC's" is not a workable solution.

We have strict security requirements that prevent machines from connecting out to certain remote DC's, these requirements are not changeable purely to circumvent a design flaw in the ACS software. I have a TAC case open regarding this same issue and have asked the operator to try and see if it's possible to put some additional pressure on to have the bug / feature request implemented in a timely manor given that it has been open for almost a year.

The other alternative is to find out if it's possible to edit the hosts file to allow me to spoof the DNS entries for the DC's so that the ACS will only ever attempt communication with servers it can contact.

If you know of a way to do this or have the ability to put some added pressure on to the bug / feature request you mentioned it would be greatly appreciated.

Thanks,

Jason

francoistetard · ‎05-24-2011

I'm in the same situation with ACS 5.0 and active directory connection issue.

I found a trick in onrder to join AD. I've configured my own dns server using a free little tool (SANS: simple authritative name Server) and created a dns zone of my domain (domain.com) and create theses entry :

SRV : _gc._tcp.domain -> port 389, server dcname.domain.com
SRV : _ldap._tcp.domain ->port 389, server dcname.domain.com
A : dcname.domain -> IP dc

I then configured the 2 ACS to use my dns server during the joining process.

With this the AD discovery is working fine.

After this, I reconfigured my ACS to use the corporate dns.

Regards

Jimmi Hvidtfeldt · ‎03-07-2012

Hey

We are facing the same issue on version 5.2

If i understand this correctly then it is only during the discovery process that the DC's are listed?

Has any other solutions been found for this issue, other than placing a new dns server which is only aware of the DC's you want to use?

jbrunstein · ‎03-08-2012

Hi Jimmi,

we finally opened a case for this matter.

Removing the content of the 'container' field in the Active Directory configuration solved the case (User & Identity Store > External User database > Active Directory)

Regards,

François Tetard

Jimmi Hvidtfeldt · ‎03-08-2012

Hey

Thanks for that swift response.

However i am not sure i understand.

I dont have any "container" filed in my config.

See screenshot below.

Really appreciate your reply as this is a huge issue for us.

e-betancourt · ‎08-20-2012

What worked for me.

Make sure there is no $ in the password. In fact make sure there are no special characters whatsover.

ciscoacg2012 · ‎08-28-2012

This solution worked for us as well. We changed the password for the service account so that it did not have any special characters in it and we were finally able to join our Active Directory domain. Prior to this change, the "Test Connection" would succeed and the "Save Changes" would fail. We're using version 5.3.0.40.5.

john.k.hall · ‎03-07-2014

Did you ever find a fix action for this problem. I am have the same issue? I am not clear on the container thing either.