12-21-2010 07:14 AM - edited 03-10-2019 05:39 PM
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
12-21-2010 07:28 AM
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: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
12-28-2010 01:53 AM
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.
12-29-2010 01:52 AM
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
05-24-2011 06:19 AM
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 :
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
03-07-2012 11:32 PM
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?
03-08-2012 12:33 AM
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
03-08-2012 12:51 AM
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.
08-20-2012 03:02 PM
What worked for me.
Make sure there is no $ in the password. In fact make sure there are no special characters whatsover.
08-28-2012 02:17 PM
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.
03-07-2014 11:39 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide