cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4382
Views
10
Helpful
6
Replies

ACS 5.1 does not join AD

ibrunello
Level 1
Level 1

We're trying to join a test ACS to our current domain.

When trying, we get a weird "cannot resolve domain" error.

When looking at debug, we get

Jan 18 2010 14:28:32 CisACS_33207 66 1 1 BL AD Operation warning , ADOperationResult=unable to create secured connection against AD server, switching to non-secured connection. javax.naming.CommunicationException: simple bind fai

led: domain01.domain.local:636 [Root exception is javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake], DomainName=domain.local, AdminName=admin-user, AdminSession=D3F9E8998F70F80EEEF763DFAB6C412B, AdminInterf

ace=GUI, AdminIPAddress=192.168.1.202

any hint.

TIA

Ivan

6 Replies 6

jweekers
Level 1
Level 1

Log onto the CLI and set the domain-name to your AD domain.

You also will need to set the DNS to point to it and set NTP to the same source - ACS will object if the time does not match.

Hope this helps,

-J

1) domain name already set.

2) DNS configured. Pinging base domain name (mydomain.local) resolves to DC

3) time server was already configured to a shared authoritative NTP. But, to ensure better timesync, we pointed the ACS to the DC.

According to a capture I did, it seems a kerberos option mismatch "KRB5KDC_ERR_ETYPE_NOSUPP"

Any other hint?

Ivan

Ivan,


Looks like When the ACS 5.1 API requests the ticket for the admin user we're getting the following error back "KRB5KDC_ERR_ETYPE_NOSUPP". Doing a quick Google search shows that the error has to do with the encryption type not being supported on that server. Also, make sure that we are not running windows 7 that could be a issue.

Few Tips:

======


ACS 5.1 has to be configured with a valid NTP server for time synchronization, preferably from where the domain controller is syncing  its time. Another one is a valid DNS server which can resolve internal names.

Both of them will be configured from the CLI:
http://www.cisco.com/en/US/partner/docs/net_mgmt/cisco_secure_access_control_system/5.1/command/reference/cli_use.html#wp1096003

ip name-server
http://www.cisco.com/en/US/partner/docs/net_mgmt/cisco_secure_access_control_system/5.1/command/reference/cli_app_a.html#wp1729536

ntp server
http://www.cisco.com/en/US/partner/docs/net_mgmt/cisco_secure_access_control_system/5.1/command/reference/cli_app_a.html#wp1013780

Once these are configured, we need to set the correct time -- matching to the domain controller time, using:

clock timezone
http://www.cisco.com/en/US/partner/docs/net_mgmt/cisco_secure_access_control_system/5.1/command/reference/cli_app_a.html#wp1036987

clock
http://www.cisco.com/en/US/partner/docs/net_mgmt/cisco_secure_access_control_system/5.1/command/reference/cli_app_a.html#wp1036987

Please reboot the ACS whenever you are asked to do so while configuring above commands.

HTH


Regards,

Jatin

Plz rate helpful posts-

~Jatin

great hint list, Jatin.

I already performed almost everything but timezone.

clock should not be needed, since NTP is set correctly.

Gonna check and let you know

BTW, domain is Windows 2000.

Ivan

Ivan,

Did you get the issue fixed?

I'm facing the same thing. Checked NTP, DNS and Domain name. All fine.

I also upgraded ACS to the latest patch 5-1-0-44-2, still the same issue.

Appreciate your help.

Thanks,

Tao

I fixed the problem.

Turned out to be an heavy DNS misconfiguration.

In short

1) there where fake srv records in _ldap._tcp.mydomain.com which mislead ACS registration process.

   Furthermore, there where also missing PTR records for domain controllers.

   Both things seems to hit ACS really heavy.

   This surprised me, since we have 50+ DC, just one wrong SRV, and 3 missing PTRs: it seems it cycles ALL records for consistency, and fails whenever it founds at least one.

    I worked around this by creating a fake DNS server with the expected records.

    (meanwhile, I asked AD/DNS people to fix it)

2) there was still a GSSAPI error, which did not allowed ACS to register the right way (i.e. first asking a kerberos ticket, and then create an encrypted session)

    Lucky for me, and shame on Cisco, when unable to make an encrypted binding, it falls back to CLEARTEXT binding, but at least it succeeds

    (I ended up creating an IPSEC tunnel between the ACS and the nearest DC, to lessen the risk of spoofing a domain admin password)

     This problem still exists.

Since all this setup was build to manage a wireless controller test, and the test ended, I stopped further testing.

Best suggestion is "WIRESHARK IS YOUR FRIEND".

I worked out everything by sniffing the current session between ACS and DNS/Domain Controllers (which happen to be on different machines).

hope this may help.

Ivan

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: