Howard Chu
2007-Sep-15 11:21 UTC
re: [Fedora-directory-users] Directory Server capabilities
> 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.htmlJust 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... -- -- 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/
Clowser, Jeff (Contractor)
2007-Sep-17 19:06 UTC
RE: [Fedora-directory-users] Directory Server capabilities (Dynamic Groups)
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 controversialfeatures 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/
Pete Rowley
2007-Sep-17 19:23 UTC
Re: [Fedora-directory-users] Directory Server capabilities (Dynamic Groups)
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 > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users >-- Pete
Richard Megginson
2007-Sep-17 19:25 UTC
Re: [Fedora-directory-users] Directory Server capabilities (Dynamic Groups)
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
Clowser, Jeff (Contractor)
2007-Sep-17 19:57 UTC
RE: [Fedora-directory-users] Directory Server capabilities (DynamicGroups)
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: fedora-directory-users-bounces@redhat.com [mailto:fedora-directory-users-bounces@redhat.com] 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 beingworked> 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
Richard Megginson
2007-Sep-17 20:00 UTC
Re: [Fedora-directory-users] Directory Server capabilities (DynamicGroups)
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: fedora-directory-users-bounces@redhat.com > [mailto:fedora-directory-users-bounces@redhat.com] 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 > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users >
matt wells
2007-Sep-17 20:04 UTC
Re: [Fedora-directory-users] Directory Server capabilities (DynamicGroups)
You can''t use any type of dynamic group with posix groups right?
Steven Jones
2007-Sep-17 23:41 UTC
[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
Steven Jones
2007-Sep-18 00:29 UTC
RE: [Fedora-directory-users] getting sh on RHAS5 to work with FDS.
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: +64 4 463 6272
________________________________
From: fedora-directory-users-bounces@redhat.com
[mailto:fedora-directory-users-bounces@redhat.com] 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
Steven Jones
2007-Sep-18 01:28 UTC
RE: [Fedora-directory-users] getting sh on RHAS5 to work with FDS.
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
Richard Megginson
2007-Sep-18 14:39 UTC
Re: [Fedora-directory-users] getting sh on RHAS5 to work with FDS.
Steven Jones
2007-Sep-19 20:44 UTC
RE: [Fedora-directory-users] getting sh on RHAS5 to work with FDS.
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: +64 4 463 6272 -----Original Message----- From: fedora-directory-users-bounces@redhat.com [mailto:fedora-directory-users-bounces@redhat.com] 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 > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users >
Richard Megginson
2007-Sep-19 21:01 UTC
Re: [Fedora-directory-users] getting sh on RHAS5 to work with FDS.
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: +64 4 463 6272 > > -----Original Message----- > From: fedora-directory-users-bounces@redhat.com > [mailto:fedora-directory-users-bounces@redhat.com] 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 >> Fedora-directory-users@redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-users >> >> > > > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users >