Re: [Fedora-directory-users] Fedora DS 1.0.2 Multiple Master SSL replication: empty bind DN...
by Kevin McCarthy
Thanks again Richard,
My attempt to determine why the bind DN remains as "" have still not located
the cause - though I guess that is due to this being my first usage and I
have merely missed the obvious!
> To ensure that you are doing client cert auth, you can examine the access
> log on the replication consumer - look for the connection and BIND from
> the supplier. If you're not sure what you're looking at, just post the
> relevant excerpts here.
I can see from the bind result that the initial "dn" is still the required:
"cn=nema2,ou=EDS,o=teligent,dc=co,c=uk"
..but the BIND dn remains as "", with the method as "sasl"?
Consumer Access log file extract:
[03/Jul/2006:10:24:11 +0100] conn=11 fd=67 slot=67 SSL connection from
192.168.27.15 to 192.168.144.61
[03/Jul/2006:10:24:11 +0100] conn=11 SSL 256-bit AES; client
CN=nema2,OU=EDS,O=teligent,DC=co,C=uk; issuer CN=CAcertnema2
[03/Jul/2006:10:24:11 +0100] conn=11 SSL client bound as
cn=nema2,ou=EDS,o=teligent,dc=co,c=uk
[03/Jul/2006:10:24:11 +0100] conn=11 op=0 BIND dn="" method=sasl version=3
mech=EXTERNAL
[03/Jul/2006:10:24:11 +0100] conn=11 op=0 RESULT err=0 tag=97 nentries=0
etime=0 dn="cn=nema2,ou=EDS,o=teligent,dc=co,c=uk"
[03/Jul/2006:10:24:11 +0100] conn=11 op=1 SRCH base="" scope=0
filter="(objectClass=*)" attrs="supportedControl supportedExtension"
[03/Jul/2006:10:24:11 +0100] conn=11 op=1 RESULT err=0 tag=101 nentries=1
etime=0
[03/Jul/2006:10:24:11 +0100] conn=11 op=2 SRCH base="" scope=0
filter="(objectClass=*)" attrs="supportedControl supportedExtension"
[03/Jul/2006:10:24:11 +0100] conn=11 op=2 RESULT err=0 tag=101 nentries=1
etime=0
[03/Jul/2006:10:24:11 +0100] conn=11 op=3 EXT oid="2.16.840.1.113730.3.5.3"
name="Netscape Replication Start Session"
[03/Jul/2006:10:24:11 +0100] conn=11 op=3 RESULT err=0 tag=120 nentries=0
etime=0
[03/Jul/2006:10:24:12 +0100] conn=11 op=4 EXT oid="2.16.840.1.113730.3.5.3"
name="Netscape Replication Start Session"
[03/Jul/2006:10:24:12 +0100] conn=11 op=4 RESULT err=0 tag=120 nentries=0
etime=0
[03/Jul/2006:10:24:15 +0100] conn=11 op=5 EXT oid="2.16.840.1.113730.3.5.3"
name="Netscape Replication Start Session"
[03/Jul/2006:10:24:15 +0100] conn=11 op=5 RESULT err=0 tag=120 nentries=0
etime=0
[03/Jul/2006:10:24:19 +0100] conn=11 op=6 EXT oid="2.16.840.1.113730.3.5.3"
name="Netscape Replication Start Session"
[03/Jul/2006:10:24:19 +0100] conn=11 op=6 RESULT err=0 tag=120 nentries=0
etime=0
[03/Jul/2006:10:24:28 +0100] conn=11 op=8 EXT oid="2.16.840.1.113730.3.5.3"
name="Netscape Replication Start Session"
[03/Jul/2006:10:24:28 +0100] conn=11 op=8 RESULT err=0 tag=120 nentries=0
etime=0
[03/Jul/2006:10:24:34 +0100] conn=10 op=4 UNBIND
[03/Jul/2006:10:24:34 +0100] conn=10 op=4 fd=64 closed - U1
[03/Jul/2006:10:24:46 +0100] conn=11 op=10 EXT oid="2.16.840.1.113730.3.5.3"
name="Netscape Replication Start Session"
[03/Jul/2006:10:24:46 +0100] conn=11 op=10 RESULT err=0 tag=120 nentries=0
etime=0
[03/Jul/2006:10:25:08 +0100] conn=11 op=12 UNBIND
[03/Jul/2006:10:25:08 +0100] conn=11 op=12 fd=67 closed - U1
Consumer Error log file extract:
[03/Jul/2006:10:24:11 +0100] NSMMReplicationPlugin - conn=11 op=3
replica="ou=EDS,o=teligent,dc=
co,c=uk": Unable to acquire replica: error: permission denied
[03/Jul/2006:10:24:12 +0100] NSMMReplicationPlugin - conn=11 op=4
replica="ou=EDS,o=teligent,dc=co,c=uk": Unable to acquire replica: error:
permission denied
[03/Jul/2006:10:24:15 +0100] NSMMReplicationPlugin - conn=11 op=5
replica="ou=EDS,o=teligent,dc=co,c=uk": Unable to acquire replica: error:
permission denied
[03/Jul/2006:10:24:19 +0100] NSMMReplicationPlugin - conn=11 op=6
replica="ou=EDS,o=teligent,dc=co,c=uk": Unable to acquire replica: error:
permission denied
[03/Jul/2006:10:24:28 +0100] NSMMReplicationPlugin - conn=11 op=8
replica="ou=EDS,o=teligent,dc=co,c=uk": Unable to acquire replica: error:
permission denied
[03/Jul/2006:10:24:46 +0100] NSMMReplicationPlugin - conn=11 op=10
replica="ou=EDS,o=teligent,dc=co,c=uk": Unable to acquire replica: error:
permission denied
[03/Jul/2006:10:24:50 +0100] NSMMReplicationPlugin - agmt="cn=EDS from
Server 1" (nema2:636): Unable to acquire replica: permission denied. The
bind dn "" does not have permission to supply replication updates to the
replica. Will retry later.
Regards and thanks again,
Kevin
From: Richard Megginson <rmeggins(a)redhat.com>
Subject: Re: [Fedora-directory-users] Fedora DS 1.0.2 Multiple Master
SSL replication: empty bind DN...
To: "General discussion list for the Fedora Directory server project."
<fedora-directory-users(a)redhat.com>
Message-ID: <44A51838.4040409(a)redhat.com>
Content-Type: text/plain; charset="windows-1252"
Kevin McCarthy wrote:
>
> Richard, thank you for your response!
>
> hopefully whatever configuration mistake I made to cause a NULL bind
> DN will soon come to light
>
> > Dear List Members,
>
> >
>
> > Release: *fedora-ds-1.0.2-1.RHEL3.i386.opt.rpm*
>
> >
>
> > A typical replication error log entry now follows (seen repeatedly at
>
> > both fedora DS servers):
>
> >
>
> > [28/Jun/2006:18:29:21 +0100] NSMMReplicationPlugin - agmt="cn=EDS from
>
> > server 2" (ukstatlap:636): Unable to acquire replica: permission
>
> > denied. The *bind dn ""* does not have permission to supply
>
> > replication updates to the replica. Will retry later.
>
> >
>
> > Believe me, I have been investigating this one for 2 or 3 days now
>
> > (having just switched from OpenLDAP, since multiple master replication
>
> > is required) before sending this submission, just in case I missed a
>
> > configuration item or work-around, but unfortunately no luck (so far).
>
> >
>
> > The only reference I can find for SSL Client Authentication based
>
> > Multiple Master replication (2 Linux RHEL 3 servers being used) that
>
> > supplies empty DNs, is the Windows specific entry (whose work-around I
>
> > tried anyway, but without success)_
>
> >
>
> > Unable to acquire replica: permission denied. The bind dn "" does not
>
> > have permission to supply replication updates to the replica. Will
>
> > retry later.
>
> > To workaround the problem, after you modify and save the replication
>
> > schedule of an agreement, refresh the console, reconfigure the
>
> > connection settings (to SSL client authentication) for the agreement,
>
> > and save your changes.
>
> >
>
> > http://www.redhat.com/docs/manuals/dir-server/release-notes/ds611relno
>
> > tes.html
>
> >
>
> > The mutual _Current Supplier DNs_ are indeed set (cn=Replication
>
> > Manager,cn=replication,cn=config) and the corresponding directory
>
> > entries do exist.
>
> >
>
> > The respective server certificates and CA certificates are installed,
>
> > with Subject DN entries loaded.
>
> >
>
> What are the SubjectDNs in the server certificates?
>
> CN=<SERVERNAME>,OU=EDS,O=teligent,DC=co,C=uk
>
> where <SERVERNAME> is the respective server name of the replicating
> servers e.g. nema2 rather than a full domain name.
>
I think this is ok, as long as your DNS (/etc/resolv.conf) configuration
can resolve nema2.
>
> The following will hopefully also be relevant:
>
> 1) The tree being replicated is OU=EDS,O=Teligent,DC=co,C=uk i.e.
> the Subject DN is within the replicated tree.
>
> 2) certutil was used to generate the server and CA certificates.
> Surprisingly (to me at least) the CA certificate was then listed in
> the "Server Certs" panel on the Directory Server Manage Certificates
> panel.
>
> 3) I loaded the ascii version of the other servers CA Certificate
> directly into the CA Certs panel.
>
> 4) All CA certificates have both the accept and make connection trusts
> ticked.
>
> > I do _not_ have Legacy Consumer enabled.
>
> >
>
> You don't need it.
>
> >
>
> > CertMapping is also defined (though with a NULL DN being supplied, I
>
> > guess that will not be kicking in just yet, though there are entries
>
> > for the exact subject DN anyway.)
>
> >
>
> You might want to post your certmap.conf and see here -
> http://directory.fedora.redhat.com/wiki/Howto:CertMapping
>
> I must admit that since the Bind DN was NULL I had not realized that
> certmapping would actually take affect.
>
If you are using client cert based auth (and not just username/password
auth with SSL) then certmapping will be used. To ensure that you are
doing client cert auth, you can examine the access log on the
replication consumer - look for the connection and BIND from the
supplier. If you're not sure what you're looking at, just post the
relevant excerpts here.
...log file extract at the head.
>
> I ensured that the exact subject DN of the server certificates
> corresponded to an actual directory entry (with the respective
> servers user certificate loaded), which I had thought would be
> matched without the need for a certmap configuration via the original
> default option, but I tried one anyway
>
> certmap nema ou=EDS,o=teligent,dc=co,c=uk
>
I think this DN should correspond to the issuerDN (i.e. the subjectDN of
your CA cert). But I don't think it's used for cert mapping.
>
> nema:FilterComps cn
>
This means you must have one and only one entry called cn=nema2, .....,
o=teligent,dc=co,c=uk somewhere in your tree.
...indeed, just the one.
>
> nema:verifycert off
>
> certmap default default
>
> indeed one server still runs with the default certmap configuration
> to see if it made any difference, but both servers receive a NULL bind
> DN .
>
This leads me to believe it is not doing client cert auth. Also check
the errors log for your supplier and consumer.
...extracts at the head.
>
> > When using simple authentication, with or without SSL, all is well
>
> > (although replication did require both servers to Initialize the
>
> > Consumer, I thought that only one was required e.g. ID 1 initializing
>
> > ID 2, but ID 2 then needed to initialize ID 1 before successful 2-way
>
> > replication was achieved).
>
> >
>
> That's odd. You should only need to initialize once one way.
>
> indeed, but I guess that it can not do any harm, as the secondary
> server will not actually need to supply any further updates back to
> the primary server and it does at least make the mutual replication
> work for me until the certificates took their toll
17 years, 2 months
[Fedora-directory-users] RPM/SRPM issues and old RHEL
by Oliver Hookins
Hi there,
I'm trying to get started testing out Fedora Directory Server with the
goal of replacing our OpenLDAP infrastructure. Most of our servers are
RHEL3/4 so there are no big issues there since there are already
prepackaged binary RPMS for those platforms.
But we do have two RHEL2.1 server which we will definitely need packages
for in order to do any migration to FDS. Upgrading these servers to
RHEL3/4 is not an option. Looking at the spec file of the SRPM from
RHEL3 it seems like dependencies won't be a problem, the spec file
itself is a mess and doesn't come close to building everything (which I
understand is a work in progress).
So my questions are: has anyone got FDS running well on RHEL2.1 (either
by compiling directly from source, shoehorning the RPM from RHEL3 or
building the RPM from the SRPM)? Has anyone written their own spec file
from scratch to build FDS in its entirety from sources? I also wanted to
change the installation prefix from /opt so getting a working and
complete spec file would be very desirable.
--
Regards,
Oliver Hookins
Anchor Systems
17 years, 2 months
[Fedora-directory-users] packaging problems.
by Hai Zaar
Dear, list,
I know that you are currently working on making FDS to be more FHS
friendly, but anyway, I've got the problem with the current packaging.
I'm building FDS-1.0.2 using dsbuild. When build finishes,
ds/ldapserver/work dir contains file
allLinux2.6_x86_glibc_PTH_OPT.OBJ.tar.gz, that, AFAIK, should be
unzipped and then ./setup should be run.
The problem is, not all of the files are packaged:
cd ds/ldapserver/work
mkdir /tmp/fds
tar zxvf allLinux2.6_x86_glibc_PTH_OPT.OBJ.tar.gz -C /tmp/fds
cd /tmp/fds && ls -la
admin base dsktune setup setup.inf slapd tmp
'svrcore' dir is missing, setup complains about it and fails. On the
onther hand, produced rpm is fine, and running setup from
ds/servercore/work/pkg dir (that looks like origin for the tarball)
succeeds.
Distro: LFS-6.1+kernel-2.6.15.
P.S. I'm not on the list, so please CC me.
--
Zaar
17 years, 2 months
Re: [Fedora-directory-users] [Fwd: migrate sendmail with fds]
by Mike Jackson
basile <basile.mathieu(a)siris.sorbonne.fr> kirjoitti:
> i have this errors in logs
>
> Jul 4 13:08:22 sorbon sm-mta[21182]: [ID 293258 mail.error] libsldap:
> Status: 91 Mesg: Error 0
> Jul 4 13:08:22 sorbon last message repeated 1 time
> Jul 4 13:08:22 xxx sm-mta[21182]: [ID 293258 mail.error] libsldap:
> Status: 7 Mesg: Session error no available conn.
Hi,
For FDS support, post FDS logs to the FDS list. We understand those.
For sendmail support, post sendmail logs to the sendmail list. They understand those.
--
mike
17 years, 3 months
[Fedora-directory-users] sendmail and fds
by basile
hi
our mail users are now in a fedora directory it works fine except :
i have this errors in logs
Jul 4 13:08:22 sorbon sm-mta[21182]: [ID 293258 mail.error] libsldap:
Status: 91 Mesg: Error 0
Jul 4 13:08:22 sorbon last message repeated 1 time
Jul 4 13:08:22 xxx sm-mta[21182]: [ID 293258 mail.error] libsldap:
Status: 7 Mesg: Session error no available conn.
Jul 4 13:08:22 xxx sm-mta[21182]: [ID 293258 mail.error] libsldap:
Status: 91 Mesg: No such file or directory
Jul 4 13:08:22 xxx last message repeated 1 time
Jul 4 13:08:22 xxx sm-mta[21182]: [ID 293258 mail.error] libsldap:
Status: 7 Mesg: Session error no available conn.
and i have a thunderbird on xp which cannot send mail ( xp , thunderbird
1.5.0.4 )
but with another instance of thunderbird ( same version on xp all works
fine )
that is very strange
if someone have any idea or experience , because we are now in production
thanks
basile
17 years, 3 months
[Fedora-directory-users] ldapadd with Kerberos
by Andrey Ivanov
Hi,
There is something I can't explain concerning the interaction of
ldapadd & ldapsearch (from openldap) with FDS while using kerberos
Here is what i do :
1. kinit User.Name
...
2. Verification with klist -ok, i have the kerberos ticket
3. Verification with ldapsearch works without any problem, giving all the necessary infos:
ldapsearch -Y GSSAPI 'sn=toto*'
SASL/GSSAPI authentication started
SASL username: User.Name@KRB-FDS
SASL SSF: 56
SASL installing layers
# extended LDIF
#
# LDAPv3
# base <> with scope sub
# filter: sn=aic*
# requesting: userPassword
.... infos ...
4. The problem appears when i try to use ldapadd/ldapmodify with some
ldif files (apparently, these files should be larger than some
critical value to produce the error)
Her is an example of such an ldif
test.ldif:
dn: cn=Gilles Martin,ou=CMLS,ou=Laboratoires,o=Some Organization,dc=fds-example,dc=domain,dc=com
givenName: Gilles
sn: Martin
telephoneNumber: 00 00
loginShell: /bin/bash
departmentNumber: LAB CMLS
physicalDeliveryOfficeName: 402:10-02
uidNumber: 3090
gidNumber: 3000
mail: gilles.martin(a)some-organization.domain.com
displayName: Gilles Martin (M.)
uid: Gilles.Martin
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
objectClass: posixAccount
gecos: Gilles Martin,LAB CMLS ,PERSONNEL DE RECHERCHE
cn: Gilles Martin
title: PERSONNEL DE RECHERCHE
homeDirectory: /home/CMLS/Gilles.Martin
userPassword: {clear}Gilles.Martin
When i try to add this entry using ldapadd or ldapmodify with kerberos :
[root@workstation ~]# ldapadd -Y GSSAPI -v -f test.ldif -H ldap://fds-example.domain.com
ldap_initialize( ldap://fds-example.domain.com )
SASL/GSSAPI authentication started
SASL username: User.Name@KRB-FDS
SASL SSF: 56
SASL installing layers
add givenName:
Gilles
add sn:
Martin
add telephoneNumber:
00 00
add loginShell:
/bin/bash
add departmentNumber:
LAB CMLS
add physicalDeliveryOfficeName:
402:10-02
add uidNumber:
3090
add gidNumber:
3000
add mail:
gilles.martin(a)some-organization.domain.com
add displayName:
Gilles Martin (M.)
add uid:
Gilles.Martin
add objectClass:
top
person
organizationalPerson
inetorgperson
posixAccount
add gecos:
Gilles Martin,LAB CMLS ,PERSONNEL DE RECHERCHE
add cn:
Gilles Martin
add title:
PERSONNEL DE RECHERCHE
add homeDirectory:
/home/CMLS/Gilles.Martin
add userPassword:
{clear}Gilles.Martin
adding new entry " cn=Gilles Martin,ou=CMLS,ou=Laboratoires,o=Some Organization,dc=fds-example,dc=domain,dc=com"
modify complete
ldap_add: Protocol error (2)
additional info: decoding error
5. Adding the same entry using simple authentification (plain text or
SSL/TLS) is possible without any problem. The only way of using
kerberos and ldapadd/ldapmodify is adding the option "-O maxssf=0" :
ldapadd -Y GSSAPI -O maxssf=0 -v -f test.ldif -H ldap://fds-example.domain.com
With this command line, the ldapadd adds the entry with success.
Can someone explain me why ldapsearch works without problem and
ldapadd needs an additional option (this option forbids the double
encryption kerberos+ssl if i understand correctly)?
Thank you!
Andrey Ivanov
tel +33-(0)1-69-33-99-24
fax +33-(0)1-69-33-99-55
Direction des Systemes d'Information
Ecole Polytechnique
91128 Palaiseau CEDEX
France
17 years, 3 months
Re: [Fedora-directory-users] New filesystem layout for directory server and admin server files
by Mike Jackson
Richard Megginson <rmeggins(a)redhat.com> kirjoitti:
> But there are a lot of people for whom this is a problem. For example, we ship 3 versions of NSPR, NSS, LDAP C SDK, ICU, etc. that are private to RHDS. In
> addition, we ship our own versions of bdb, cyrus sasl, netsnmp, and other software that are in most cases identical to what is already included or available for
> the OS. To remedy this situation, we are going to switch FDS/RHDS to build and run against those OS libraries, and to not include them in the DS package.
> So we are already committed to not including all of the dependencies in an isolated manner. This change will affect the linux and solaris ports. I'm not sure
> how it will affect the HP-UX port. HP already takes our software and repackages it in the HP-UX depot format.
Argh. This is also a strength of the FDS software, not a problem or weakness. The package always works because it always includes exactly what it needs. Using OS libraries can cause all sorts of unpredictable problems. IMO, removing the included dependencies is also a bad idea. My list of reasons on the plus side for FDS/RHDS vs OL are being reduced, strangely. One would have thought that the package could only get better, not worse.
Consider Symas, how they compile and deliver CDS, which is intended to be a supportable product for commercial customers. They put the entire chain of dependencies and software into /opt/symas, so CDS doesn't break everytime somebody installs a new buggy OS level bdb or OL library on the machine. There's a good reason for that; it is then a supportable product. Trusting the proper operation of your critically important software to the random quality and version numbers of system libraries is not wise.
BTW, when is the autoconf support coming? The patch was submitted quite a while ago, IIRC...
BR,
--
mike
17 years, 3 months
[Fedora-directory-users] Retrieving User Password From Fedora Directory Server
by Hariharan R
Dear all,
I am using FDS 7.2 on FC3 for my development. I am storing userprofile
along with user password to the FDS database (BDB). When i look the user
profile in console i seen that the password value has been encrypted.
Fine. If i do 'ldapsearch' , it doesn't returns the 'userpassword'
attribute and its value.
How i can get the userPassword attribute and it's value using LDAP
search command. Is there is any way to convert the encrypted password to
plain text one.
I am in an urgent need , so please any one guide me.
Thanks in advance.
---
Regards,
Hariharan.R
17 years, 3 months
Re: [Fedora-directory-users] New filesystem layout for directory server and admin server files
by Mike Jackson
Les Mikesell <lesmikesell(a)gmail.com> kirjoitti:
>
>
> Moving locations is always traumatic. Personally I like
> stand-alone packages that aren't going to be installed on
> every machine you have to live under /opt, but if it is
> ever going to move, do it soon to minimize the number of
> people who will be affected by already having it installed
> in the wrong place.
As FDS is the basis of a commercial product, RHDS, let's talk about the commercial aspect for a moment. Things which are changed in FDS will eventually go into RHDS. There are already folks with lots of RHDS servers deployed or being deployed into commercial environments. We are already talking about a large number of installations.
One of the reasons why I argue so strongly to use RHDS in commercial environments is that it includes all dependencies in an isolated manner, and doesn't change interfaces often. IMO, those features make it currently the most suitable server for commercial usage.
To the people who are complaining about the filesystem layout, understand that FDS is the basis for a complex and _stable_ commercial product. You don't just start fiddling with it if it ain't broken... Moving to FHS is certainly not going to increase sales or product stability, although it might make a few systems engineers who have never heard of RFC 2251 happy for a day or two.
Or am I wrong to assume that these type of proposed changes would also make it into RHDS?
--
mike
17 years, 3 months
