cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6780
Views
0
Helpful
7
Replies

Cisco ACS 5.1 cannot join Windows AD

markus.menzi
Level 1
Level 1

For about a week now I am setting up our new ACS 5.1. I have experienced no problems so far up until now when trying to join the ACS with the Windows AD (configuring LDAP was also no problem). I configure it using the domain name, a user and password with the appropriate rights.

When I hit the "Test Conection" button I get the message "Connection test to 'mydomain.com' succeeded".


However, when I want to save the configuration, I get the message "Invalid credentials to join this machine to Active Directory Domain". Tests with different users made no difference at all. Now for the interesting part. According to the log files, the ACS contacted the following servers to join the AD:


Jul 26 15:00:45 mbssp087 adjoin[4848]: INFO  cli.adjoin Version: CentrifyDC 4.3.0-184
Jul 26 15:01:34 mbssp087 adjoin[4848]: INFO  base.bind.ad ConnectToServer: fetch("") from p10174.mydomain.ch:389 failed (Reason: fetch  : Can't contact LDAP server)
Jul 26 15:01:39 mbssp087 adjoin[4848]: INFO  base.bind.ad ConnectToServer: fetch("") from p10589.mydomain.ch:389 failed (Reason: fetch  : Can't contact LDAP server)
Jul 26 15:01:44 mbssp087 adjoin[4848]: INFO  base.bind.ad ConnectToServer: fetch("") from p10504.mydomain.ch:389 failed (Reason: fetch  : Can't contact LDAP server)
Jul 26 15:01:54 mbssp087 adjoin[4848]: INFO  base.bind.ad ConnectToServer: fetch("") from p10853.mydomain.ch:389 failed (Reason: fetch  : Can't contact LDAP server)
Jul 26 15:02:04 mbssp087 adjoin[4848]: INFO  base.bind.ad ConnectToServer: fetch("") from p4831.mydomain.ch:389 failed (Reason: fetch  : Can't contact LDAP server)
Jul 26 15:02:14 mbssp087 adjoin[4848]: INFO  base.bind.ad ConnectToServer: fetch("") from p10159.mydomain.ch:389 failed (Reason: fetch  : Can't contact LDAP server)
Jul 26 15:02:19 mbssp087 adjoin[4848]: INFO  base.bind.ad Reached adclient.server.try.max before finding a valid server
Jul 26 15:02:19 mbssp087 adjoin[4848]: INFO  cli.adjoin Join to domain 'mydomain.ch', zone 'null' failed.


The pxxxx.mydomain.ch entries one can see in the log files are not DC's at all. Those are ordinary workstations all across our branch network. According to our windows administrator, all is set up correctly on the DNS or DC servers.

Browsing through the support forums I made sure that I set the ntp, timezone and dns servers correctly. The ACS is patched to version 5.1.0.44-3, all DC's are Windows 2000 machines.

Any ideas what I am overlooking? I am sure it's just a little detail I am not seeing...

7 Replies 7

markus.menzi
Level 1
Level 1

After rechecking every configuration option I found the following. The DC's have as a timezone GMT+1, on my ACS I had Etc/Zurich configured, resulting in the same time but not in the same timezone. Changed it to Etc/GMT+1 and guess what? The time is three hours earlier than GMT+1 on the DC's.

After configuring Etc/GMT+4, the time again went 3 hours backwards. How comes? On all the devices I had been working with, +1 means really +1. But on the ACS, things work differently. Now I have Etc/GMT-2, and the time is again correct, but resulting again in a different timezone.

One last question, how can I configure the daylight time saving option (something like "clock summer-time GMT+2 recurring last Sun Mar 2:00 last Sun Oct 3:00")?

Thanks in advance.

Some comments I found related to timezone setting

In ACS we are not changing the default behavior of Linux WRT timezone notation.
This is the notation used by Linux for GMT offset.  It's the POSIX notation as described below:

# We use POSIX-style signs in the Zone names and the output abbreviations,
# even though this is the opposite of what many people expect.
# POSIX has positive signs west of Greenwich, but many people expect
# positive signs east of Greenwich.  For example, TZ='Etc/GMT+4' uses
# the abbreviation "GMT+4" and corresponds to 4 hours behind UTC
# (i.e. west of Greenwich) even though many people would expect it to
# mean 4 hours ahead of UTC (i.e. east of Greenwich).

Example:
- The time is 10am GMT+0 (sync'd via NTP).
- If we configure the timezone on ACS to Etc/GMT-1, the clock changes to 11am.
- If we configure the timezone on ACS to Etc/GMT+1, the clock changes to 9am.

Thank you jrabinow for clearing that up.

The timezone must be identical to the ones on the DC's. Now I have GMT-2 on the ACS and GMT+1 (with daylight saving) on the DC's. Does that mean now that the timezones are identical? Or will the values of -2 or +1 also be considered by the adjoin process?

The six workstations that can be seen in my first post, our windows administrator has deleted every single reference to these machines in our AD. And yet the ACS still wants to connect to them when trying to join the AD. I do not understand that.

What I am gonna do next is installing my second ACS 5.1 (out of the box; with no patches at all), see what happens when I wanna join it. Then apply the latest patch and try to join the AD again. If the behavior is the same, I gonna open a request via our partner. ACS 5.1 is really a great product, but not being able to join it to the AD is a real show stopper.

Thanks again for your time.

Our windows administrator found several invalid SRV entries in his AD configuration thingie. He deleted those and now we only have the valid entries. But after trying to join the AD again, the ACS tries to contact the very same DC's (the invalid ones) again.

I rebooted the ACS in hopes that maybe a local cache on the ACS gets purged, but that did not help. If the ACS has them entries cached, is there any command to purge them?

If there is a cache somewhere else in the AD, what must be done to purge that aswell? Our windows administrator claims no action is necessary and it should be active immediately.

Thanks again.

Now I installed the whole ACS again from scratch. And yet the ACS still finds the very same DC's when I try to join it to the AD domain.

Our windows administrator has deleted all the faulty SRV entries, and the ACS still finds them. There is nothing more he can do he says, or he needs to know exactly how that AD join process works.

From my point of view there is a problem *somewhere* in the AD environement, but I cannot point the finger at it. Are there any windows super-guru's about that could lead me to the right direction on what to do now? I am simply lost at the moment...

We did check every DC in our domain and ran every test that was suggested in the following thread:

http://technet.microsoft.com/en-us/library/bb727055.aspx

And yet there is no change. ACS still finds those DC's that are not DC's at all. Guess I'll just have to wait for Cisco to release a new patch that lets us choose what DC's to use or some other configuration method.

I had simmilar problem with login/joining to AD.

I need know how to setup uniq IP for domain.name to /etc/hosts

Or how to setup default domain controller fo domain.

All setup options for AD and users are OK as user privilegue level on AD, ntp ...

We have on infrastructure more domain controllers and DNS servers with different architecture.

Few with 32bit few with 64bit, few as unix controllers, few as win controllers .....

Q: How to setup default controller IP for domain.

Ideal solution is /etc/hosts update and setting server IP for domain controllers.

====================================================

From ACS CLI:

====================================================

acs-new/acsadmin# nslookup xx.domain.com

Trying "xx.domain.com"

;; Truncated, retrying in TCP mode.

Trying "xx.domain.com"

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35020

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 75, AUTHORITY: 0, ADDITIONAL: 25

;; QUESTION SECTION:

;xx.domain.com.                 IN      ANY

;; ANSWER SECTION:

xx.domain.com.          600     IN      A       192.168.21.19

xx.domain.com.          600     IN      A       10.249.4.41

xx.domain.com.          600     IN      A       10.245.1.19

xx.domain.com.          600     IN      A       10.250.20.1

xx.domain.com.          600     IN      A       10.241.2.29

xx.domain.com.          600     IN      A       172.16.90.83

xx.domain.com.          600     IN      A       10.247.10.5

xx.domain.com.          600     IN      A       10.244.48.100

xx.domain.com.          600     IN      A       10.242.53.218

xx.domain.com.          600     IN      A       10.242.52.202

xx.domain.com.          600     IN      A       172.21.8.32

xx.domain.com.          600     IN      A       10.16.1.29

xx.domain.com.          600     IN      A       10.254.99.182

xx.domain.com.          600     IN      A       10.245.48.229

xx.domain.com.          600     IN      A       10.100.8.19       !# me default controllers

xx.domain.com.          600     IN      A       10.224.201.10

xx.domain.com.          600     IN      A       10.254.100.2

xx.domain.com.          600     IN      A       10.243.18.13

xx.domain.com.          600     IN      A       10.249.4.1

xx.domain.com.          600     IN      A       10.249.4.2

xx.domain.com.          600     IN      A       172.31.4.26

xx.domain.com.          600     IN      A       10.241.2.28

xx.domain.com.          600     IN      A       10.245.48.235

xx.domain.com.          600     IN      A       172.31.4.21

xx.domain.com.          600     IN      A       10.242.52.201

xx.domain.com.          600     IN      A       10.243.18.14

xx.domain.com.          600     IN      A       10.240.1.16

xx.domain.com.          600     IN      A       172.21.8.33

xx.domain.com.          600     IN      A       10.224.201.1

xx.domain.com.          600     IN      A       10.254.152.214

xx.domain.com.          600     IN      A       10.100.17.81       !# me default controllers

xx.domain.com.          600     IN      A       10.253.116.158

xx.domain.com.          600     IN      A       10.100.17.80

xx.domain.com.          600     IN      A       10.250.20.2

xx.domain.com.          600     IN      A       10.241.20.231

xx.domain.com.          600     IN      A       10.253.116.161

xx.domain.com.          600     IN      A       10.244.48.120

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: