cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1439
Views
5
Helpful
7
Replies

VCS not trusting certificate - User LDAP configuration

tornygard1
Level 1
Level 1

I have a cluster of 2 Telepresence VCS-control in same network(vlan) and a cluster of 2 Telepresence Expressway in same DMZ network(vlan). And both are on the same site. On both master peers I have succeded to synch the servers against the ldap server(AD), but the two slave`s with identical config for users/certificate/ldap settings are not successful. .  "DNS uable to resolve LDAP server address. It seems to me that the peers don`t trust the certificate.

1 Accepted Solution

Accepted Solutions

The logs you attached are event logs and not diagnostic logs from the VCS. However from these logs it appears that the VCS slave is not able to establish a connection with the ldap server. So the DNS resolution is probably taking place, but the tcp/tls connection is not establishing.

 

I would recommend getting a diagnostic log (Maintenance > Diagnostics > Diagnostic logging) while reproducing the connection failure to see what part in the connection is failing.

 

If you have root access to the VCS Slave you could also login as root via ssh and then issue the following command:

 

> tcpdump -s0 tcp port <ldap connection port>

 

Insert the port you are using to connect to ldap in the <ldap connection port> field and then press enter. you will now see all traffic to and from that port. Do you see any resets? Is the traffic in one direction? This should help to figure out why the failure is occurring.

View solution in original post

7 Replies 7

Chad Patterson
Cisco Employee
Cisco Employee

2 things to try here:

 

1) On each peer that is failing to connect to LDAP, go to Maintenance > Tools > Network Utilities > DNS Lookup and try to perform a few DNS lookups. Are you able to resolve anything? This test confirms you have DNS reach-ability. If this fails then you have a potential firewall/ACL issue. If this succeeds, then try option 2.

 

2) Start a diagnostic log on the peers that are failing. Then try to sync them with LDAP. Once it fails stop the diagnostic log. Filter on the IP or FQDN address you specified for the LDAP server and see if any error messages are thrown. You should get an error/warning if there is a certificate trust issue. If you are using encryption on the LDAP configuration, make sure that the AD server’s certificate is signed by an authority within the VCS peers trusted CA certificates list.

1. Done that. And it is resolving correct. I have done this together with the guys responsible for firewalls, AD and DNS.

2. Also done that. I have as I mentioned earlier VCS control in a luster (master and slave), in the same subnet, same certificates and same ldap configuration. So if the master trust the certificate, why don`t the slave trust the same certificate, same firewall, same site same rack and same switch

Did the diagnostic log not give you any more information? Also what makes you think it is a certificate issue in the first place? If you attach the log perhaps we can help you take a look.
 

Ok, I`ll do that tomorrow when I`m at work again :)

Ok, here`s the logs. One from the master(working), and one from the slave(not working), But when using the DNS lookup tool I receive a response from the server with correct IP.

The logs you attached are event logs and not diagnostic logs from the VCS. However from these logs it appears that the VCS slave is not able to establish a connection with the ldap server. So the DNS resolution is probably taking place, but the tcp/tls connection is not establishing.

 

I would recommend getting a diagnostic log (Maintenance > Diagnostics > Diagnostic logging) while reproducing the connection failure to see what part in the connection is failing.

 

If you have root access to the VCS Slave you could also login as root via ssh and then issue the following command:

 

> tcpdump -s0 tcp port <ldap connection port>

 

Insert the port you are using to connect to ldap in the <ldap connection port> field and then press enter. you will now see all traffic to and from that port. Do you see any resets? Is the traffic in one direction? This should help to figure out why the failure is occurring.

Sorry for not following up this post until now, but here`s an excerpt of the log.

2015-07-13T14:50:33+02:00 server002 httpd[24520]: web: Event="Authorization Failure" Detail="Failed to authenticate; User cannot be authenticated by PAM" User="David
2015-07-13T14:50:33+02:00 server002 httpd[24520]: web: User="David" Event="Admin Session Login Failure" Src-ip="10.0.0.1" Src-port="43037" UTCTime="2015-07-13 12:50:33"

 

VCS-C-Master looks like this:

2015-07-13T15:30:50+02:00 node001 taa-chkpasswd: UTCTime="2015-07-13 13:30:50,651" Module="pam_unix(taa-chkpasswd-webadmin:auth)" Level="NOTICE"  CodeLocation="support.c(835)" Pid="9321" Thread="0" Detail="authentication failure; logname= uid=2 euid=0 tty= ruser= rhost=  user= David "
2015-07-13T15:30:51+02:00 node001 taa-chkpasswd: Event="pam" Module="pam_unix(taa-chkpasswd-webadmin:session)" Level="INFO"  Detail="session opened for user David by (uid=2)" UTCTime="2015-07-13 13:30:51"
2015-07-13T15:30:51+02:00 node001 taa-chkpasswd: UTCTime="2015-07-13 13:30:51,204" Module="pam_lastlog(taa-chkpasswd-webadmin:session)" Level="ERROR"  CodeLocation="pam_lastlog.c(218)" Pid="9321" Thread="0" Detail="failed to lseek /var/log/lastlog: Invalid argument"
2015-07-13T15:30:51+02:00 node001 httpd[18921]: web: User="David" Event="Admin Session Start" Src-ip="10.0.0.1" Src-port="28141" UTCTime="2015-07-13 13:30:51"
 

TCP Dump from the failing server (Slave):

61 Alert (Level: Fatal, Description: Unknown CA) 

 

If you need the complete logs, is it a way to send them to you without publishing them here?

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: