Using tls_cert/key without rootbinddn

View: New views
6 Messages — Rating Filter:   Alert me  

Using tls_cert/key without rootbinddn

by Iain Morgan :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hello,

I'm attempting to configure nss_ldap/pam_ldap to use a client SSL cert
when binding to Sun's Directory Server. The intent is to avoid using
rootbinddn and binddn altogether.

While I can successfully bind to the server using the client cert, the
client immediately attempts to rebind using simple authentication:

[21/Feb/2007:10:45:03 -0800] conn=3829 op=-1 msgId=-1 - fd=17 slot=17
LDAPS connection from 10.2.9.13:31250 to 10.2.9.209
[21/Feb/2007:10:45:03 -0800] conn=3829 op=-1 msgId=-1 - SSL 56-bit
RC4-56; client CN=HEC Proxy,OU=Proxy,O=NASA Advanced Supercomputing
Division; issuer CN=Temporary CA,O=NASA Advanced Supercomputing
Division
[21/Feb/2007:10:45:03 -0800] conn=3829 op=-1 msgId=-1 - SSL client bound
as cn=HEC Proxy,ou=Proxy,dc=nas,dc=nasa,dc=gov
[21/Feb/2007:10:45:03 -0800] conn=3829 op=0 msgId=1 - BIND dn=""
method=128 version=3
[21/Feb/2007:10:45:03 -0800] conn=3829 op=0 msgId=1 - RESULT err=0
tag=97 nentries=0 etime=0 dn=""

The /etc/ldap.conf is simply:

uri ldaps://linux09.nas.nasa.gov
base dc=nas,dc=nasa,dc=gov
ldap_version 3

pam_password clear

ssl on
tls_cert /etc/ssl/private/HEC_client.pem
tls_key /etc/ssl/private/HEC_client.key

Is there any way to avoid this apparent rebinding?

Thnks

--
Iain Morgan

Re: Using tls_cert/key without rootbinddn

by Howard Chu :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Iain Morgan wrote:

> Hello,
>
> I'm attempting to configure nss_ldap/pam_ldap to use a client SSL cert
> when binding to Sun's Directory Server. The intent is to avoid using
> rootbinddn and binddn altogether.
>
> While I can successfully bind to the server using the client cert, the
> client immediately attempts to rebind using simple authentication:
>
> [21/Feb/2007:10:45:03 -0800] conn=3829 op=-1 msgId=-1 - fd=17 slot=17
> LDAPS connection from 10.2.9.13:31250 to 10.2.9.209
> [21/Feb/2007:10:45:03 -0800] conn=3829 op=-1 msgId=-1 - SSL 56-bit
> RC4-56; client CN=HEC Proxy,OU=Proxy,O=NASA Advanced Supercomputing
> Division; issuer CN=Temporary CA,O=NASA Advanced Supercomputing
> Division
> [21/Feb/2007:10:45:03 -0800] conn=3829 op=-1 msgId=-1 - SSL client bound
> as cn=HEC Proxy,ou=Proxy,dc=nas,dc=nasa,dc=gov
> [21/Feb/2007:10:45:03 -0800] conn=3829 op=0 msgId=1 - BIND dn=""
> method=128 version=3
> [21/Feb/2007:10:45:03 -0800] conn=3829 op=0 msgId=1 - RESULT err=0
> tag=97 nentries=0 etime=0 dn=""
>
> The /etc/ldap.conf is simply:
>
> uri ldaps://linux09.nas.nasa.gov
> base dc=nas,dc=nasa,dc=gov
> ldap_version 3
>
> pam_password clear
>
> ssl on
> tls_cert /etc/ssl/private/HEC_client.pem
> tls_key /etc/ssl/private/HEC_client.key
>
> Is there any way to avoid this apparent rebinding?
>  
You need to configure nss_ldap to use SASL binds. But in the version I'm
looking at (248, pretty old) it only supports SASL/GSSAPI, and you want
it to use SASL/EXTERNAL. Patching "GSSAPI" to "EXTERNAL" would be
sufficient in ldap-nss.c:do_bind(). Really the mechanism ought to be a
config keyword.

--
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc
  Chief Architect, OpenLDAP     http://www.openldap.org/project/


Re: Using tls_cert/key without rootbinddn

by Hallvard B Furuseth :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Iain Morgan writes:
> While I can successfully bind to the server using the client cert, the
> client immediately attempts to rebind using simple authentication:

Note that sending a client cert with TLS is not an LDAP Bind.  It does
sends credentials which can be _used_ in an LDAP Bind (SASL/EXTERNAL).

--
Hallvard

Re: Using tls_cert/key without rootbinddn

by Iain Morgan :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Sometime ago, Hallvard B Furuseth wrote:

> Iain Morgan writes:
> > While I can successfully bind to the server using the client cert, the
> > client immediately attempts to rebind using simple authentication:
>
> Note that sending a client cert with TLS is not an LDAP Bind.  It does
> sends credentials which can be _used_ in an LDAP Bind (SASL/EXTERNAL).
>
> --
> Hallvard
>

Thanks to both you and Howard Chu for pointing out my misunderstanding
and pointing me in the direction of SASL/EXTERNAL.

Cheers

--
Iain Morgan

Re: Using tls_cert/key without rootbinddn

by lambam80 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

If I've understood correctly:

Note that sending a client-cert with TLS does *not perform* an LDAP Bind.

Q1. Do we know what purpose it serves, then (sending a client-cert when we need account/password)?
Password in clear text only, if I've understood correctly :-(

< and pointing me in the direction of SASL/EXTERNAL.

I also misunderstood ! Can you please elaborate on the use of SASL/EXTERNAL ? For example, what options
did you use in /etc/ldap.conf ?

Thanks for your time.

Re: Using tls_cert/key without rootbinddn

by lambam80 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Iain was kind enought to reply offline. I'll put his comments here.

> Note that sending a client-cert with TLS does *not perform* an LDAP Bind.

> > Q1. Do we know what purpose it serves, then ? Why bother specifying client cert, and key, in the file /etc/ldap.conf ?  

Requiring clients to offer a cert signed by a specific trusted CA wouldprovide a means of
disallowing 'foreign' hosts from usefully being ableto access and LDAPS server.

> > Aside: If I've understood correctly the password (bindpw secret) in the file /etc/ldap.conf is only supported in clear text :-(

That is correct.

> < and pointing me in the direction of SASL/EXTERNAL.
> > I also misunderstood ! Can you please elaborate on the use of SASL/EXTERNAL ? For example, what options
> did you use in /etc/ldap.conf to enable SASL/EXTERNAL?

Due to other constraints, SASL/EXTERNAL was not pursued.