Jump to content
Welcome to our new Citrix community!

Netscaler LDAP over SSL issue


Recommended Posts

Hi,

I got an issue with setting up a NS v11 to communicate to a remote ldap server over TLS. I checked my ldap server and it works. I tested the TLS connection to my server and the TLS connection is good.

The only error I can find is this message in the lb vserver:

State: DOWN[Certkey not bound]

 

And this log:

default AAA Message 1403 0 :  "In update_aaa_cntr: Failed policy for user xxxxxxx

 

ANy thoughts on the issue?

 

Thank you

Link to comment
Share on other sites

Are you configuring an ldap lb vserver, an authentication policy, or a aaa vserver where you see the error?

Do you have a server certificate bound to the LB Vserver of type TCP_SSL?

Certkey not bound means you have a SSL or SSL_TCP entity and no cert specified.

 

If setting up ldap vserver or services, be sure the vserver has a cert bound, and the ldap monitor (if used) is configured with secure flag on.

AAA vservers also require a ssl cert to be bound.

 

 

Otherwise, show your config for the entity in question:

show ns runningconfig | grep <entity name> -i

 

 

Link to comment
Share on other sites

(note: I'm real new at Citrix stuff and a bit confused)

I have an lb vserver (example not real values) set for 1.1.1.1:636. I have an authentication ldappolicy set to the same ip and port with secure type set to SSL.

I also created a ssl service with a trusted root ca bound to the lb vserver. (I have the same setup for syslog over TLS and it works fine, only difference is the ldapPolicy).

when I attempt to bind a cert to lb vserver it tells me it's not a server cert. And that's where the confusion starts. Why would I set a server cert when it's acting as a client to connect to my remote ldap server.

Link to comment
Share on other sites

See if this helps:

 

A server cert is the cert that is issued the FQDN of the LB vserver and is therefore used to verify the identity of the vserver when a client connects to it.

The server cert is NOT a root ca cert; instead it consists of a certificate and a private key.  Your CA certificate on your services IS not the server cert on the lb vserver.

 

2 hours ago, Thibaut Marconnet said:

Why would I set a server cert when it's acting as a client to connect to my remote ldap server.

 

NS to server (aka the service side of the transaction) the NS is the client connecting to the backend.

However, client to LB Vserver, the lb vserver is the "server" in the transaction.  Client can't talk to the lb vserver over SSL without a cert. If this is for your ldap load balancing, even if the client is just the NS talking to teh authentication services, it needs a cert on the vserver to establish the frontend connection as ssl.

 

So when you add a cert to a web server on a backend and bind via IIS, you are assigning a server cert to that server so connections can trust the identity of the server they connect to.

When you create an LB vserver on the ADC (Netscaler), you need to create a server cert issued to the FQDN of the lb vserver. This gets bound to the lb vserver.

You can use whatever CA you want to issue this cert, such as a domain CA for internal users or a public CA for external users.

Clients need to trust the issuer of your server cert on the lb vserver.

 

Example:

# import/create certkey for server certificate (lots of ways); this is a brief example

add ssl certkey web.domain.com-certkey -cert <cert1.cer> -keyfile <key1.pem> -password

# Create service for backend entities

#   Root Cert bindings may or may not be required; certs on these services allows Ns to trust server it is connecting too (if required)

add service svc_web1 <ip1> ssl 443

add service svc_web2 <ip2> ssl 443

# Create lb vserver

add lb vserver lb_vsrv_demo ssl <VIP> 443

   bind lb vserver lb_vsrv_demo svc_web1

   bind lb vserver lb_vsrv_demo svc_web2

# bind server cert to lb vserver

   bind ssl vserver lb_vsrv_demo -certkey web.domain.com-certkey

   # this certkey must be a server cert, which contains the server identity (issued by a trusted CA) and a reference to the private key.

 

Link to comment
Share on other sites

20 hours ago, Rhonda Rowland1709152125 said:

See if this helps:

 

A server cert is the cert that is issued the FQDN of the LB vserver and is therefore used to verify the identity of the vserver when a client connects to it.

The server cert is NOT a root ca cert; instead it consists of a certificate and a private key.  Your CA certificate on your services IS not the server cert on the lb vserver.

 

 

NS to server (aka the service side of the transaction) the NS is the client connecting to the backend.

However, client to LB Vserver, the lb vserver is the "server" in the transaction.  Client can't talk to the lb vserver over SSL without a cert. If this is for your ldap load balancing, even if the client is just the NS talking to teh authentication services, it needs a cert on the vserver to establish the frontend connection as ssl.

 

So when you add a cert to a web server on a backend and bind via IIS, you are assigning a server cert to that server so connections can trust the identity of the server they connect to.

When you create an LB vserver on the ADC (Netscaler), you need to create a server cert issued to the FQDN of the lb vserver. This gets bound to the lb vserver.

You can use whatever CA you want to issue this cert, such as a domain CA for internal users or a public CA for external users.

Clients need to trust the issuer of your server cert on the lb vserver.

 

Example:

# import/create certkey for server certificate (lots of ways); this is a brief example

add ssl certkey web.domain.com-certkey -cert <cert1.cer> -keyfile <key1.pem> -password

# Create service for backend entities

#   Root Cert bindings may or may not be required; certs on these services allows Ns to trust server it is connecting too (if required)

add service svc_web1 <ip1> ssl 443

add service svc_web2 <ip2> ssl 443

# Create lb vserver

add lb vserver lb_vsrv_demo ssl <VIP> 443

   bind lb vserver lb_vsrv_demo svc_web1

   bind lb vserver lb_vsrv_demo svc_web2

# bind server cert to lb vserver

   bind ssl vserver lb_vsrv_demo -certkey web.domain.com-certkey

   # this certkey must be a server cert, which contains the server identity (issued by a trusted CA) and a reference to the private key.

 

I have to give it a try. Thank you. I'll let you know if that worked

 

Link to comment
Share on other sites

1) When you give the NS a direct IP for authentication services, it usually uses the NSIP to reach the destination. Whereas traffic via the vserver uses the SNIP.

2) If your lb vserver was of type TCP, but you were trying to do Secure Ldap, then it wouldn't work. Or if your lb vserver was SSL_TCP:636, but when you configured the secure ldap in the authentication profile, you did or didn't change the port to match....

 

So, either the vserver/service didn't match the actual authentication destination protocol/port.

OR, the authentication policy/action protocol/port didn't match your lb vserver for authentication (or persistence was wrong)

OR the SNIP couldn't reach the destination.

 

It could have been multiple issues.  But glad you found something that worked. Though a trace may help you figure out the original problem if you need to turn secure ldap back on.

Link to comment
Share on other sites

If you still want to diagnose the original problem, try the following. If using the direct IP allows you to move on, then you can disregard.

 

What are the SSL settings in the authentication policy action?

Is it set for HTTP or SSL/TLS and does it specify the correct port 636 (instead of 389) that matches your ldap settings?

Do you have any settings in the action that require validating the cert and is the right hostname for the cert specified?

Do the details in the action match the lb vserver for the authentication traffic details (destination Ip, ssl_tcp, port, and cert details).

Finally, which version of NS are you on and check the release notes to see if there is a bug and that its not just a configuration issue.

 

And do a trace to see if there is a communication failure between NS and destination.

 

The original issue was that the certkey wasn't bound to the lb vserver, so until that is fixed none of the load balancing config in the authentication policy would work.  so there may have been multiple overlapping issues.

 

 

Link to comment
Share on other sites

14 hours ago, Rhonda Rowland1709152125 said:

If you still want to diagnose the original problem, try the following. If using the direct IP allows you to move on, then you can disregard.

 

What are the SSL settings in the authentication policy action?

Is it set for HTTP or SSL/TLS and does it specify the correct port 636 (instead of 389) that matches your ldap settings?

Do you have any settings in the action that require validating the cert and is the right hostname for the cert specified?

Do the details in the action match the lb vserver for the authentication traffic details (destination Ip, ssl_tcp, port, and cert details).

Finally, which version of NS are you on and check the release notes to see if there is a bug and that its not just a configuration issue.

 

And do a trace to see if there is a communication failure between NS and destination.

 

The original issue was that the certkey wasn't bound to the lb vserver, so until that is fixed none of the load balancing config in the authentication policy would work.  so there may have been multiple overlapping issues.

 

 

 

Hi,

The ldapAction is set for SSL. with [ldapserveripaddress]:636. The "validate LDAP server certificate is set to NO. the only thing I had that would have done hostname certificate match was the ssl service I created. 

The lb vserver was set to 6.6.1.1:636 that matches the NSIP I created.

Where I'm confused is I thought I had to have an ssl service attached to the lb vserver to handle to TLS connection.

I followed a few steps that I wrote down a while ago and it worked just fine and I guess I messed something up because it stopped working and I couldn't fix it unless I removed the ssl service and changed the IP address in the ldapAction to the ldap' server ip address insead of the lb vserver.

 

Link to comment
Share on other sites

SSL vserver/services on NetScaler mean HTTPS traffic.

SSL_TCP would have been the traffic type for Secure LDAP.

 

For ldap load balancing with end-to-end SSL, the basic setup should have been:

add service svc_ldap1 <ip1> ssl_tcp 636

add service svc_ldap2 <ip2> ssl_tcp 636

# certs needed for services

 

add lb vserver lb_vsrv_ldap ssl_tcp <VIP1> 636

bind lb vserver lb_vsrv_ldap svc_ldap1

bind lb vserver lb_vsrv_ldap svc_ldap2

bind ssl vserver lb_vsrv_ldap -certkey <certkeyname>

 

# Just be sure you use a backend facing VIP.

Then in your authentication policy, point to the VIP of this vserver and specify the SSL/TLS setting and port.

 

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...