re: [Fedora-directory-users] Directory Server capabilities

[Howard Chu]

> From: "Clowser, Jeff (Contractor)" <jeff_clowser fanniemae com>
> Date: Fri, 14 Sep 2007 14:58:53 -0400
> I have a question about capabilities in the Fedora/RH Directory server:
>
> First, can it do dynamic groups as Novell eDirectory does (or is there any
> effort to add this): 
> http://support.novell.com/techcenter/articles/ana20020405.html

Just fyi, the Novell guys have also published this spec as an Internet Draft.
http://tools.ietf.org/html/draft-haripriya-dynamicgroup-02

The spec is full of flaws, however, as discussed here:
http://www.openldap.org/lists/ietf-ldapext/200702/threads.html

If this approach to dynamic groups is of interest to you, you should probably 
get involved in the discussion and give some feedback.
> Basically, it's similar to the groupofURL's that is supported by the RH/Sun
> directory server, but when the group is retrieved, dn's for entries that
> match the ldap url dynamic criteria is returned added to the uniquemember
> attribute, and you can do searches/compares on the uniquemember attribute
> that includes dynamic members.

Note that uniqueMember is a useless attribute in LDAP. Likewise the 
NameAndOptionalUID syntax (which is the syntax of uniqueMember) is totally 
misused in LDAP and should be avoided by modern software.
> I realise there are some significant performance considerations with this,
> but for modest use, it would really be useful.  (FWIW, I asked a similar
> question when FDS first was released, but didn't have another product to
> point to as a comparable implementation at the time.  Haven't looked at FDS
> for a while, so I'm hoping some things might have changed :)  )

As a footnote, OpenLDAP supports some of the less controversial features of 
dynamic groups and has for quite some time already...

[Fedora-directory-users] Directory Server capabilities (Dynamic Groups)

[Clowser, Jeff]

OK - I see the following in openldap:
http://linux.die.net/man/5/slapo-dynlist

My previous example was Novell eDirectory, but this works just as well
or better 
for what I'm looking for (I actually like this better because I can
dynamically
generate more than just group members, but even that would be enough.)

So...  Any chance that something like this is available or being worked
on for FDS?
> ...
> As a footnote, OpenLDAP supports some of the less controversial

features of
> dynamic groups and has for quite some time already...
>
> -- 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/

[Fedora-directory-users] Directory Server capabilities (Dynamic Groups)

[Pete Rowley]

Clowser, Jeff (Contractor) wrote:
> OK - I see the following in openldap:
> http://linux.die.net/man/5/slapo-dynlist
>
> My previous example was Novell eDirectory, but this works just as well
> or better 
> for what I'm looking for (I actually like this better because I can
> dynamically
> generate more than just group members, but even that would be enough.)
>
> So...  Any chance that something like this is available or being worked
> on for FDS?

Roles:

http://www.redhat.com/docs/manuals/dir-server/deploy/7.1/dit.html#15038
http://www.redhat.com/docs/manuals/dir-server/ag/7.1/roles.html#1115402
> > ...
> > As a footnote, OpenLDAP supports some of the less controversial
>
> features of
> > dynamic groups and has for quite some time already...
> >
> > -- 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/
>
> --
> Fedora-directory-users mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/fedora-directory-users

[Fedora-directory-users] Directory Server capabilities (Dynamic Groups)

[Rich Megginson]

Clowser, Jeff (Contractor) wrote:
> OK - I see the following in openldap:
> http://linux.die.net/man/5/slapo-dynlist
>
> My previous example was Novell eDirectory, but this works just as well
> or better 
> for what I'm looking for (I actually like this better because I can
> dynamically
> generate more than just group members, but even that would be enough.)
>
> So...  Any chance that something like this is available or being worked
> on for FDS?

Not that I know of, but this does seem like a generally useful feature.  
Please file an enhancement request for this feature at bugzilla.redhat.com

[Fedora-directory-users] Directory Server capabilities (DynamicGroups)

[Clowser, Jeff]

While looking at the openldap overlays, I also saw a "slapo-constraint"
overlay:

"slapo-constraint - Constraint checking of attribute-values provides a
convenient method for enforcing local policy for directory content when
the existing standard schema syntax rules are too lenient. Both
character sets and full regular expressions are supported."

That kind of functionality would be really useful in FDS as well, if
it's not there already :)

- Jeff

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Richard
Megginson
Sent: Monday, September 17, 2007 3:26 PM
To: General discussion list for the Fedora Directory server project.
Subject: Re: [Fedora-directory-users] Directory Server capabilities
(DynamicGroups)

Clowser, Jeff (Contractor) wrote:
> OK - I see the following in openldap:
> http://linux.die.net/man/5/slapo-dynlist
>
> My previous example was Novell eDirectory, but this works just as well
> or better 
> for what I'm looking for (I actually like this better because I can
> dynamically
> generate more than just group members, but even that would be enough.)
>
> So...  Any chance that something like this is available or being

worked
> on for FDS?

Not that I know of, but this does seem like a generally useful feature.

Please file an enhancement request for this feature at
bugzilla.redhat.com

[Fedora-directory-users] Directory Server capabilities (DynamicGroups)

[Rich Megginson]

Clowser, Jeff (Contractor) wrote:
> While looking at the openldap overlays, I also saw a "slapo-constraint"
> overlay:
>
> "slapo-constraint - Constraint checking of attribute-values provides a
> convenient method for enforcing local policy for directory content when
> the existing standard schema syntax rules are too lenient. Both
> character sets and full regular expressions are supported."
>
> That kind of functionality would be really useful in FDS as well, if
> it's not there already :)

No, Fedora DS doesn't have that either.
> Jeff
>
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Richard
> Megginson
> Sent: Monday, September 17, 2007 3:26 PM
> To: General discussion list for the Fedora Directory server project.
> Subject: Re: [Fedora-directory-users] Directory Server capabilities
> (DynamicGroups)
>
> Clowser, Jeff (Contractor) wrote:
> > OK - I see the following in openldap:
> > http://linux.die.net/man/5/slapo-dynlist
> >
> > My previous example was Novell eDirectory, but this works just as well
> > or better 
> > for what I'm looking for (I actually like this better because I can
> > dynamically
> > generate more than just group members, but even that would be enough.)
> >
> > So...  Any chance that something like this is available or being
>
> worked
> > on for FDS?
>
> Not that I know of, but this does seem like a generally useful feature.
>
> Please file an enhancement request for this feature at
> bugzilla.redhat.com
>
> --
> Fedora-directory-users mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/fedora-directory-users

[Fedora-directory-users] Directory Server capabilities (DynamicGroups)

[Matt Wells]

You can't use any type of dynamic group with posix groups right?

[Fedora-directory-users] getting sh on RHAS5 to work with FDS.

[Steven Jones]

It seems the settings needed to get RHAS5 going differ to RHAS4....

This is how I did RHAS4, any ideas what additions or changes are needed
for RHAS5?

The client connects to the server but fails to get a password......I
disabled TLS but it still fails suggesting something a bit more
fundamental....

Red Hat AS4 client ssl setup

First thing, scp the ca cert over, otherwise you may not be able to scp
it over once you have edited some of the files below.

On the server if you have not already done so generate the certificate,

cd /opt/fedora-ds/alias ; cp cacert.asc /etc/openldap/cacerts/`openssl
x509 \
-noout -hash -in cacert.asc`.0

There will now be two files of interest,

-rw-r--r--  1 root root   619 Sep 17 16:27 5be5959f.0
-rw-r--r--  1 root root   619 Sep 17 16:27 cacert.asc

On the server, tar these into a file move the certificate over to the
client via scp,

Move them to /etc/openldap/cacerts/

And create a symbolic link,

ln -s 5be5959f.0  ca.crt

-rw-r--r--  1 root root   619 Sep 17 16:27 5be5959f.0
-rw-r--r--  1 root root   619 Sep 17 16:27 cacert.asc
lrwxrwxrwx  1 root root    10 Sep 17 16:44 ca.crt -> 5be5959f.0

Check dependancies,

rpm -q nss_ldap , needs to be installed.

Move to the ldap directory and backup the files,

cd /etc/openldap ; cp ldap.conf no-ssl-fully-working-ldap.conf \

cd /etc/ ; cp ldap.conf no-ssl-fully-working-ldap.conf

ssh uses the /etc/ldap.conf,

edit /etc/ldap.conf to this,

===============
# http://www.padl.com
URI     ldap://ldap.vuw.ac.nz
base dc=vuw,dc=ac,dc=nz
pam_password md5
BASE dc=vuw,dc=ac,dc=nz
tls_cacertfile /etc/openldap/cacerts/ca.crt
TLS_REQCERT allow
host ldap.vuw.ac.nz
ssl start_tls
===============

Set up nsswitch.conf

Change,

=========
#passwd:    db files ldap nis
#shadow:    db files ldap nis
#group:     db files ldap nis
=========

To,

=========
passwd:     files ldap
shadow:     files ldap
group:      files ldap
=========

Setup /etc/pam.d/ssh

=========
auth sufficient /lib/security/pam_ldap.so use_first_pass
account sufficient /lib/security/pam_ldap.so use_first_pass
password sufficient /lib/security/pam_ldap.so use_first_pass
=========

Check settings for /etc/ssh/sshd_config

=========
#UsePAM no
UsePAM yes
=========

UsePAM has to be set to yes.

Restart ssh and try to connect to the client, the access log on the
server should show "start_TLS" and "SSL 256-bit AES".

============
[root@vuwunicvfdsm001 logs]# tail -f access
[18/Sep/2007:06:15:14 +1200] conn=2370 op=-1 fd=74 closed - B1
[18/Sep/2007:06:15:18 +1200] conn=2376 fd=71 slot=71 connection from
130.195.87.250 to 130.195.87.249
[18/Sep/2007:06:15:18 +1200] conn=2376 op=0 EXT
oid="1.3.6.1.4.1.1466.20037" name="startTLS"
[18/Sep/2007:06:15:18 +1200] conn=2376 op=0 RESULT err=0 tag=120
nentries=0 etime=0
[18/Sep/2007:06:15:18 +1200] conn=2376 SSL 256-bit AES
8><-----------

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

Another test you can do is,

ldapsearch -x -ZZ '(uid=jonesst1)'

Output on the client will typically be,

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

# extended LDIF

#

# LDAPv3

# base <> with scope sub

# filter: (uid=jonesst1)

# requesting: ALL

#

# jonesst1, People, vuw.ac.nz

dn: uid=jonesst1,ou=People,dc=vuw,dc=ac,dc=nz

givenName: Steven

sn: Jones

loginShell: /bin/bash

uidNumber: 500

gidNumber: 500

objectClass: top

objectClass: person

objectClass: organizationalPerson

objectClass: inetorgperson

objectClass: posixAccount

uid: jonesst1

cn: Steven Jones

homeDirectory: /home/jonesst1

# search result

search: 3

result: 0 Success

# numResponses: 2

# numEntries: 1

On the server check the access log for "startTLS",

[root@vuwunicvfdsm001 logs]# tail -f access

[14/Sep/2007:12:52:59 +1200] conn=30 fd=67 slot=67 connection from
130.195.87.250 to 130.195.87.249

[14/Sep/2007:12:52:59 +1200] conn=30 op=0 EXT
oid="1.3.6.1.4.1.1466.20037" name="startTLS"

[14/Sep/2007:12:52:59 +1200] conn=30 op=0 RESULT err=0 tag=120
nentries=0 etime=0

[14/Sep/2007:12:52:59 +1200] conn=30 SSL 256-bit AES

[14/Sep/2007:12:52:59 +1200] conn=30 op=1 BIND dn="" method=128
version=3

[14/Sep/2007:12:52:59 +1200] conn=30 op=1 RESULT err=0 tag=97 nentries=0
etime=0 dn=""

[14/Sep/2007:12:52:59 +1200] conn=30 op=2 SRCH base="dc=vuw,dc=ac,dc=nz"
scope=2 filter="(uid=jonesst1)" attrs=ALL

[14/Sep/2007:12:52:59 +1200] conn=30 op=2 RESULT err=0 tag=101
nentries=1 etime=0

[14/Sep/2007:12:52:59 +1200] conn=30 op=3 UNBIND

[14/Sep/2007:12:52:59 +1200] conn=30 op=3 fd=67 closed - U1

NB. If you get (-11) errors this suggests a ca.crt issue....

regards

Steven

[Fedora-directory-users] getting sh on RHAS5 to work with FDS.

[Steven Jones]

I am also getting this error,

[root@vuwunicoadmin01 etc]# service sshd restart

Stopping sshd:                                             [  OK  ]

Starting sshd:                                             [  OK  ]

[root@vuwunicoadmin01 etc]# ldapsearch -x -ZZ '(uid=jonesst1)'

ldap_start_tls: Connect error (-11)

additional info: error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

[root@vuwunicoadmin01 etc]#

Yet ldapsearch works ok,

[root@vuwunicoadmin01 etc]# ldapsearch -x -b
"ou=People,dc=vuw,dc=ac,dc=nz"

# extended LDIF

#

# LDAPv3

# base <ou=People,dc=vuw,dc=ac,dc=nz> with scope subtree

# filter: (objectclass=*)

# requesting: ALL

#

# People, vuw.ac.nz

dn: ou=People,dc=vuw,dc=ac,dc=nz

ou: People

objectClass: top

objectClass: organizationalunit

# jonesst1, People, vuw.ac.nz

dn: uid=jonesst1,ou=People,dc=vuw,dc=ac,dc=nz

givenName: Steven

sn: Jones

loginShell: /bin/bash

uidNumber: 500

gidNumber: 500

objectClass: top

objectClass: person

objectClass: organizationalPerson

objectClass: inetorgperson

objectClass: posixAccount

uid: jonesst1

cn: Steven Jones

homeDirectory: /home/jonesst1

# search result

search: 2

result: 0 Success

# numResponses: 3

# numEntries: 2

regards

Steven Jones
Senior  Linux/Unix/San/Vmware System Administrator
APG -Technology Integration Team
Victoria University of Wellington
Phone: [phone]

________________________________

From: [e-mail]
[mailto:[e-mail]] On Behalf Of Steven
Jones
Sent: Tuesday, 18 September 2007 11:42 a.m.
To: General discussion list for the Fedora Directory server project.
Subject: [Fedora-directory-users] getting sh on RHAS5 to work with FDS.

It seems the settings needed to get RHAS5 going differ to RHAS4....

This is how I did RHAS4, any ideas what additions or changes are needed
for RHAS5?

The client connects to the server but fails to get a password......I
disabled TLS but it still fails suggesting something a bit more
fundamental....

Red Hat AS4 client ssl setup

First thing, scp the ca cert over, otherwise you may not be able to scp
it over once you have edited some of the files below.

On the server if you have not already done so generate the certificate,

cd /opt/fedora-ds/alias ; cp cacert.asc /etc/openldap/cacerts/`openssl
x509 \
-noout -hash -in cacert.asc`.0

There will now be two files of interest,

-rw-r--r--  1 root root   619 Sep 17 16:27 5be5959f.0
-rw-r--r--  1 root root   619 Sep 17 16:27 cacert.asc

On the server, tar these into a file move the certificate over to the
client via scp,

Move them to /etc/openldap/cacerts/

And create a symbolic link,

ln -s 5be5959f.0  ca.crt

-rw-r--r--  1 root root   619 Sep 17 16:27 5be5959f.0
-rw-r--r--  1 root root   619 Sep 17 16:27 cacert.asc
lrwxrwxrwx  1 root root    10 Sep 17 16:44 ca.crt -> 5be5959f.0

Check dependancies,

rpm -q nss_ldap , needs to be installed.

Move to the ldap directory and backup the files,

cd /etc/openldap ; cp ldap.conf no-ssl-fully-working-ldap.conf \

cd /etc/ ; cp ldap.conf no-ssl-fully-working-ldap.conf

ssh uses the /etc/ldap.conf,

edit /etc/ldap.conf to this,

===============
# http://www.padl.com
URI     ldap://ldap.vuw.ac.nz
base dc=vuw,dc=ac,dc=nz
pam_password md5
BASE dc=vuw,dc=ac,dc=nz
tls_cacertfile /etc/openldap/cacerts/ca.crt
TLS_REQCERT allow
host ldap.vuw.ac.nz
ssl start_tls
===============

Set up nsswitch.conf

Change,

=========
#passwd:    db files ldap nis
#shadow:    db files ldap nis
#group:     db files ldap nis
=========

To,

=========
passwd:     files ldap
shadow:     files ldap
group:      files ldap
=========

Setup /etc/pam.d/ssh

=========
auth sufficient /lib/security/pam_ldap.so use_first_pass
account sufficient /lib/security/pam_ldap.so use_first_pass
password sufficient /lib/security/pam_ldap.so use_first_pass
=========

Check settings for /etc/ssh/sshd_config

=========
#UsePAM no
UsePAM yes
=========

UsePAM has to be set to yes.

Restart ssh and try to connect to the client, the access log on the
server should show "start_TLS" and "SSL 256-bit AES".

============
[root@vuwunicvfdsm001 logs]# tail -f access
[18/Sep/2007:06:15:14 +1200] conn=2370 op=-1 fd=74 closed - B1
[18/Sep/2007:06:15:18 +1200] conn=2376 fd=71 slot=71 connection from
130.195.87.250 to 130.195.87.249
[18/Sep/2007:06:15:18 +1200] conn=2376 op=0 EXT
oid="1.3.6.1.4.1.1466.20037" name="startTLS"
[18/Sep/2007:06:15:18 +1200] conn=2376 op=0 RESULT err=0 tag=120
nentries=0 etime=0
[18/Sep/2007:06:15:18 +1200] conn=2376 SSL 256-bit AES
8><-----------

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

Another test you can do is,

ldapsearch -x -ZZ '(uid=jonesst1)'

Output on the client will typically be,

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

# extended LDIF

#

# LDAPv3

# base <> with scope sub

# filter: (uid=jonesst1)

# requesting: ALL

#

# jonesst1, People, vuw.ac.nz

dn: uid=jonesst1,ou=People,dc=vuw,dc=ac,dc=nz

givenName: Steven

sn: Jones

loginShell: /bin/bash

uidNumber: 500

gidNumber: 500

objectClass: top

objectClass: person

objectClass: organizationalPerson

objectClass: inetorgperson

objectClass: posixAccount

uid: jonesst1

cn: Steven Jones

homeDirectory: /home/jonesst1

# search result

search: 3

result: 0 Success

# numResponses: 2

# numEntries: 1

On the server check the access log for "startTLS",

[root@vuwunicvfdsm001 logs]# tail -f access

[14/Sep/2007:12:52:59 +1200] conn=30 fd=67 slot=67 connection from
130.195.87.250 to 130.195.87.249

[14/Sep/2007:12:52:59 +1200] conn=30 op=0 EXT
oid="1.3.6.1.4.1.1466.20037" name="startTLS"

[14/Sep/2007:12:52:59 +1200] conn=30 op=0 RESULT err=0 tag=120
nentries=0 etime=0

[14/Sep/2007:12:52:59 +1200] conn=30 SSL 256-bit AES

[14/Sep/2007:12:52:59 +1200] conn=30 op=1 BIND dn="" method=128
version=3

[14/Sep/2007:12:52:59 +1200] conn=30 op=1 RESULT err=0 tag=97 nentries=0
etime=0 dn=""

[14/Sep/2007:12:52:59 +1200] conn=30 op=2 SRCH base="dc=vuw,dc=ac,dc=nz"
scope=2 filter="(uid=jonesst1)" attrs=ALL

[14/Sep/2007:12:52:59 +1200] conn=30 op=2 RESULT err=0 tag=101
nentries=1 etime=0

[14/Sep/2007:12:52:59 +1200] conn=30 op=3 UNBIND

[14/Sep/2007:12:52:59 +1200] conn=30 op=3 fd=67 closed - U1

NB. If you get (-11) errors this suggests a ca.crt issue....

regards

Steven

[Fedora-directory-users] getting sh on RHAS5 to work with FDS.

[Steven Jones]

An "improved" ldap.conf (with no ssl/TLS) for RHAS5

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

# http://www.padl.com

base dc=vuw,dc=ac,dc=nz

pam_password md5

BASE dc=vuw,dc=ac,dc=nz

TLS_REQCERT never

uri ldap://ldap.vuw.ac.nz/

ssl no

tls_cacertdir /etc/openldap/cacerts

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

Trying TLS with,

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

#ssl setup

# http://www.padl.com

base dc=vuw,dc=ac,dc=nz

pam_password md5

BASE dc=vuw,dc=ac,dc=nz

TLS_REQCERT allow

#TLS_REQCERT never

host ldap.vuw.ac.nz

ssl start_tls

uri ldap://ldap.vuw.ac.nz/

tls_cacertdir /etc/openldap/cacerts

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

Produces this error,

[root@vuwunicoadmin01 etc]# ldapsearch -x -ZZ '(uid=jonesst1)'

ldap_start_tls: Connect error (-11)

additional info: TLS: hostname does not match CN in peer
certificate

Which is an interesting error.....

regards

Steven

[Fedora-directory-users] getting sh on RHAS5 to work with FDS.

[Rich Megginson]

Steven Jones wrote:
> An “improved” ldap.conf (with no ssl/TLS) for RHAS5
>
> ===============
>
> # http://www.padl.com
>
> base dc=vuw,dc=ac,dc=nz
>
> pam_password md5
>
> BASE dc=vuw,dc=ac,dc=nz
>
> TLS_REQCERT never
>
> uri ldap://ldap.vuw.ac.nz/
>
> ssl no
>
> tls_cacertdir /etc/openldap/cacerts
>
> ===============
>
> Trying TLS with,
>
> ===============
>
> #ssl setup
>
> # http://www.padl.com
>
> base dc=vuw,dc=ac,dc=nz
>
> pam_password md5
>
> BASE dc=vuw,dc=ac,dc=nz
>
> TLS_REQCERT allow
>
> #TLS_REQCERT never
>
> host ldap.vuw.ac.nz
>
> ssl start_tls
>
> uri ldap://ldap.vuw.ac.nz/
>
> tls_cacertdir /etc/openldap/cacerts
>
> ===============
>
> Produces this error,
>
> [root@vuwunicoadmin01 etc]# ldapsearch -x -ZZ '(uid=jonesst1)'
>
> ldap_start_tls: Connect error (-11)
>
> additional info: TLS: hostname does not match CN in peer certificate
>
> Which is an interesting error…..

Yes, very.
http://directory.fedoraproject.org/wiki/Howto:SSL#Basic_Steps
<quote>

NOTE - *Do not use cn=server-cert for your server certificate*. In step 
7 of the linked instructions, it says to use certutil .... -s 
cn=server-cert - this will cause clients to fail to validate the cert. 
Instead, you must use the fully qualified domain name of your server 
host as the value of the cn attribute in the subject DN. For example, if 
your directory server hostname is foo.example.com, use

../shared/bin/certutil -S -n "Server-Cert" -s cn=foo.example.com -c "CA certificate" \
-t "u,u,u" -m 1001 -v 120 -d . -z noise.txt -f pwdfile.txt

to generate your server cert. This is the minimum. You may wish to 
provide your clients with more details about your server. For more 
information, see RFC 1485 http://www.ietf.org/rfc/rfc1485.txt. You 
could choose to specify the subject DN like this:

../shared/bin/certutil ... -s "cn=foo.example.com,ou=engineering,o=example corp,c=us" ...

</quote>

Note that this also means that if you use cn=foo.example.com, clients 
must be able to resolve the server's IP address to "foo.example.com". If 
you don't care/can't do this, then use TLS_REQCERT never in your 
/etc/openldap/ldap.conf to make ldapsearch stop complaining. I highly 
recommend you do not do this though.
> regards
>
> Steven
>
> --
> Fedora-directory-users mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/fedora-directory-users

[Fedora-directory-users] getting sh on RHAS5 to work with FDS.

[Steven Jones]

Hi,

Ahhhh, I made good notes as I went along and I think can see my error,

============
7.	Generate the server certificate: 
../shared/bin/certutil -S -n "Server-Cert" -s \
"cn=vuw.ac.nz" -c "CA certificate" -t "u,u,u" -m 1001 -v \
120 -d . -z noise.txt -f pwdfile.txt
============

cn should have been "vuwunicvfdsm001.vuw.ac.nz" and not "vuw.ac.nz".....

RHAS4 cannot check too closely as it seems to be working, for Debian and
RHAS5 not....

So, if I have multiple LDAP [master] servers each LDAP server's key
needs installing on the client?  Slaves as well?

I though of a DNS issue but that looks OK.

Thanks,

Steven Jones
Senior  Linux/Unix/San/Vmware System Administrator
APG -Technology Integration Team
Victoria University of Wellington
Phone: [phone]

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Richard
Megginson
Sent: Wednesday, 19 September 2007 2:40 a.m.
To: General discussion list for the Fedora Directory server project.
Subject: Re: [Fedora-directory-users] getting sh on RHAS5 to work with
FDS.

Steven Jones wrote:
> An "improved" ldap.conf (with no ssl/TLS) for RHAS5
>
> ===============
>
> # http://www.padl.com
>
> base dc=vuw,dc=ac,dc=nz
>
> pam_password md5
>
> BASE dc=vuw,dc=ac,dc=nz
>
> TLS_REQCERT never
>
> uri ldap://ldap.vuw.ac.nz/
>
> ssl no
>
> tls_cacertdir /etc/openldap/cacerts
>
> ===============
>
> Trying TLS with,
>
> ===============
>
> #ssl setup
>
> # http://www.padl.com
>
> base dc=vuw,dc=ac,dc=nz
>
> pam_password md5
>
> BASE dc=vuw,dc=ac,dc=nz
>
> TLS_REQCERT allow
>
> #TLS_REQCERT never
>
> host ldap.vuw.ac.nz
>
> ssl start_tls
>
> uri ldap://ldap.vuw.ac.nz/
>
> tls_cacertdir /etc/openldap/cacerts
>
> ===============
>
> Produces this error,
>
> [root@vuwunicoadmin01 etc]# ldapsearch -x -ZZ '(uid=jonesst1)'
>
> ldap_start_tls: Connect error (-11)
>
> additional info: TLS: hostname does not match CN in peer certificate
>
> Which is an interesting error.....

Yes, very.
http://directory.fedoraproject.org/wiki/Howto:SSL#Basic_Steps
<quote>

NOTE - *Do not use cn=server-cert for your server certificate*. In step 
7 of the linked instructions, it says to use certutil .... -s 
cn=server-cert - this will cause clients to fail to validate the cert. 
Instead, you must use the fully qualified domain name of your server 
host as the value of the cn attribute in the subject DN. For example, if

your directory server hostname is foo.example.com, use

../shared/bin/certutil -S -n "Server-Cert" -s cn=foo.example.com -c "CA
certificate" \
-t "u,u,u" -m 1001 -v 120 -d . -z noise.txt -f pwdfile.txt

to generate your server cert. This is the minimum. You may wish to 
provide your clients with more details about your server. For more 
information, see RFC 1485 http://www.ietf.org/rfc/rfc1485.txt. You 
could choose to specify the subject DN like this:

../shared/bin/certutil ... -s
"cn=foo.example.com,ou=engineering,o=example corp,c=us" ...

</quote>

Note that this also means that if you use cn=foo.example.com, clients 
must be able to resolve the server's IP address to "foo.example.com". If

you don't care/can't do this, then use TLS_REQCERT never in your 
/etc/openldap/ldap.conf to make ldapsearch stop complaining. I highly 
recommend you do not do this though.
> regards
>
> Steven

------------------------------------------------------------------------
> --
> Fedora-directory-users mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/fedora-directory-users

[Fedora-directory-users] getting sh on RHAS5 to work with FDS.

[Rich Megginson]

Steven Jones wrote:
> Hi,
>
> Ahhhh, I made good notes as I went along and I think can see my error,
>
> ============
> 7.	Generate the server certificate: 
> ../shared/bin/certutil -S -n "Server-Cert" -s \
> "cn=vuw.ac.nz" -c "CA certificate" -t "u,u,u" -m 1001 -v \
> 120 -d . -z noise.txt -f pwdfile.txt
> ============
>
> cn should have been "vuwunicvfdsm001.vuw.ac.nz" and not "vuw.ac.nz".....
>
> RHAS4 cannot check too closely as it seems to be working, for Debian and
> RHAS5 not....
>
> So, if I have multiple LDAP [master] servers each LDAP server's key
> needs installing on the client?

No, only the CA cert.  An SSL client only needs the CA cert.
> Slaves as well?

Each server will need its own server cert and key, and the CA cert.
> I though of a DNS issue but that looks OK.
>
> Thanks,
>
> Steven Jones
> Senior  Linux/Unix/San/Vmware System Administrator
> APG -Technology Integration Team
> Victoria University of Wellington
> Phone: [phone]
>
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Richard
> Megginson
> Sent: Wednesday, 19 September 2007 2:40 a.m.
> To: General discussion list for the Fedora Directory server project.
> Subject: Re: [Fedora-directory-users] getting sh on RHAS5 to work with
> FDS.
>
> Steven Jones wrote:
> > An "improved" ldap.conf (with no ssl/TLS) for RHAS5
> >
> > ===============
> >
> > # http://www.padl.com
> >
> > base dc=vuw,dc=ac,dc=nz
> >
> > pam_password md5
> >
> > BASE dc=vuw,dc=ac,dc=nz
> >
> > TLS_REQCERT never
> >
> > uri ldap://ldap.vuw.ac.nz/
> >
> > ssl no
> >
> > tls_cacertdir /etc/openldap/cacerts
> >
> > ===============
> >
> > Trying TLS with,
> >
> > ===============
> >
> > #ssl setup
> >
> > # http://www.padl.com
> >
> > base dc=vuw,dc=ac,dc=nz
> >
> > pam_password md5
> >
> > BASE dc=vuw,dc=ac,dc=nz
> >
> > TLS_REQCERT allow
> >
> > #TLS_REQCERT never
> >
> > host ldap.vuw.ac.nz
> >
> > ssl start_tls
> >
> > uri ldap://ldap.vuw.ac.nz/
> >
> > tls_cacertdir /etc/openldap/cacerts
> >
> > ===============
> >
> > Produces this error,
> >
> > [root@vuwunicoadmin01 etc]# ldapsearch -x -ZZ '(uid=jonesst1)'
> >
> > ldap_start_tls: Connect error (-11)
> >
> > additional info: TLS: hostname does not match CN in peer certificate
> >
> > Which is an interesting error.....
>
> Yes, very.
> http://directory.fedoraproject.org/wiki/Howto:SSL#Basic_Steps
>
> <quote>
>
> NOTE - *Do not use cn=server-cert for your server certificate*. In step 
> 7 of the linked instructions, it says to use certutil .... -s 
> cn=server-cert - this will cause clients to fail to validate the cert. 
> Instead, you must use the fully qualified domain name of your server 
> host as the value of the cn attribute in the subject DN. For example, if
>
> your directory server hostname is foo.example.com, use
>
> ../shared/bin/certutil -S -n "Server-Cert" -s cn=foo.example.com -c "CA
> certificate" \
> -t "u,u,u" -m 1001 -v 120 -d . -z noise.txt -f pwdfile.txt
>
> to generate your server cert. This is the minimum. You may wish to 
> provide your clients with more details about your server. For more 
> information, see RFC 1485 http://www.ietf.org/rfc/rfc1485.txt. You 
> could choose to specify the subject DN like this:
>
> ../shared/bin/certutil ... -s
> "cn=foo.example.com,ou=engineering,o=example corp,c=us" ...
>
> </quote>
>
> Note that this also means that if you use cn=foo.example.com, clients 
> must be able to resolve the server's IP address to "foo.example.com". If
>
> you don't care/can't do this, then use TLS_REQCERT never in your 
> /etc/openldap/ldap.conf to make ldapsearch stop complaining. I highly 
> recommend you do not do this though.
> > regards
> >
> > Steven
> > --
> > Fedora-directory-users mailing list
> > [e-mail]
> > https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
> --
> Fedora-directory-users mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/fedora-directory-users