Question on certificate storage
by Orion Poplawski
I'm trying to setup MMR with another office site. We're trying to connect
over SSL, but my server gives the error:
[23/Sep/2011:12:00:56 -0600] slapi_ldap_bind - Error: could not send bind
request for id [cn=Replication Manager,cn=config] mech [SIMPLE]: error 81
(Can't contact LDAP server) -8179 (Peer's Certificate issuer is not
recognized.) 11 (Resource temporarily unavailable)
I've added what I believe are the proper CA certs (it is a chain of 3) for the
remote server to my directory server via the 389-console and manage
certificates. However, I noticed that when I use certutil on the server to
list the certificates, I don't see them:
# certutil -d /etc/dirsrv/slapd-cora/ -L
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
CA certificate CT,,
server-cert u,u,u
I would have thought they would be stored in the same place. If not, where
are the one listed in the console stored? Does it matter that they aren't
showing up with certutil?
Anything else I can do to debug the SSL connection?
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
12 years, 7 months
Epel-testing Repo
by Curran Woodward
Hello,
I can no longer install 389-ds with the below epel-testing.repo. It was working fine last week:
[epel-testing]
name=Extra Packages for Enterprise Linux 6 - Testing - $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/testing/6/$basearch
mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=testing-epel6&...
failovermethod=priority
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6
Does anyone have a current epel-testing.repo that works?
Thanks!
Curran
12 years, 7 months
389-adminutil package dependency issues fresh install
by Aaron Oas
I recently spent hours resolving a packaging issue when trying to install 389-ds 1.2.9.9, and thought I would share my finding, which is that the recent 389-adminutil-1.1.14 package version seems to have gone backwards in the library versions it provides.
My system is on Centos 5.5, 64bit, using the regular epel repos with mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=epel-5&arch=$....
I have been installing and uninstalling 389-ds over the past few weeks as I develop and prove out a migration of our ldap server, using a script to manage the yum installs/erases and related cleanup so that my results would be consistent. I started getting dependency problems after 1.2.9.9 came out, like:
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package 389-ds.noarch 0:1.2.1-1.el5 set to be updated
--> Processing Dependency: 389-ds-console-doc for package: 389-ds
--> Processing Dependency: 389-ds-console for package: 389-ds
--> Processing Dependency: 389-admin-console-doc for package: 389-ds
--> Processing Dependency: 389-admin-console for package: 389-ds
--> Processing Dependency: 389-dsgw for package: 389-ds
--> Processing Dependency: 389-console for package: 389-ds
--> Running transaction check
---> Package 389-admin-console.noarch 0:1.1.8-1.el5 set to be updated
---> Package 389-admin-console-doc.noarch 0:1.1.8-1.el5 set to be updated
---> Package 389-console.noarch 0:1.1.7-1.el5 set to be updated
---> Package 389-ds-console.noarch 0:1.2.6-1.el5 set to be updated
---> Package 389-ds-console-doc.noarch 0:1.2.6-1.el5 set to be updated
---> Package 389-dsgw.x86_64 0:1.1.7-1.el5 set to be updated
--> Processing Dependency: libadmsslutil.so.1()(64bit) for package: 389-dsgw
--> Processing Dependency: libadminutil.so.1()(64bit) for package: 389-dsgw
--> Finished Dependency Resolution
389-dsgw-1.1.7-1.el5.x86_64 from epel has depsolving problems
--> Missing Dependency: libadmsslutil.so.1()(64bit) is needed by package 389-dsgw-1.1.7-1.el5.x86_64 (epel)
389-dsgw-1.1.7-1.el5.x86_64 from epel has depsolving problems
--> Missing Dependency: libadminutil.so.1()(64bit) is needed by package 389-dsgw-1.1.7-1.el5.x86_64 (epel)
Error: Missing Dependency: libadminutil.so.1()(64bit) is needed by package 389-dsgw-1.1.7-1.el5.x86_64 (epel)
Error: Missing Dependency: libadmsslutil.so.1()(64bit) is needed by package 389-dsgw-1.1.7-1.el5.x86_64 (epel)
You could try using --skip-broken to work around the problem
You could try running: package-cleanup --problems
package-cleanup --dupes
rpm -Va --nofiles --nodigest
The program package-cleanup is found in the yum-utils package.
[root@ds03 ~]# rpm -q --provides 389-adminutil
adminutil = 1.1.14-1.el5
libadminutil.so.0()(64bit)
libadmsslutil.so.0()(64bit)
389-adminutil = 1.1.14-1.el5
I started doing a yum clean all in between every install to make sure there were no issues. I still failed every time, then suddenly 10 minutes later, an install worked. I successfully reinstalled with my script a few times, then the next time it failed again with the same dependency complaint.
Ultimately, it turned out that I was sometimes getting 389-adminutil-1.1.13-1.el5 and sometimes getting 389-adminutil-1.1.14-1.el5 as I hit different mirrors after each yum clean all. The version that resolves the dependency requirements is the *lesser* version: 389-adminutil-1.1.13-1.el5. What is odd to me is that the older 389-adminutil 1.1.13 version supplies an apparently higher version of libadminutil and libadmsslutil:
rpm -q --provides 389-adminutil
adminutil = 1.1.13-1.el5
libadminutil.so.1()(64bit)
libadmsslutil.so.1()(64bit)
389-adminutil = 1.1.13-1.el5
I.e., 389-adminutil-1.1.14 provides libadminutil.so.0, and 389-adminutil-1.1.13 provides libadminutil.so.1
I haven't gone so far as to dig into which mirrors were providing which versions, but I hope this helps someone else in the same boat, and perhaps even helps the repo or mirror retainers if there is something wrong there.
- Aaron
12 years, 7 months
Re: [389-users] SSL Error on Startup
by Rich Megginson
On 09/20/2011 07:45 AM, Chris Ober wrote:
> Rich,
>
> I've read that, and I believe I've followed the steps shown there, but
> it doesn't solve my problem.
let's start with perms/ownership
ls -al /etc/dirsrv/slapd-instance
grep nsslapd-localuser /etc/dirsrv/slapd-instance/dse.ldif
see what the server cert name is
grep -i personality /etc/dirsrv/slapd-instance/dse.ldif
next, look at certutil
certutil -d /etc/dirsrv/slapd-instance -L
certutil -d /etc/dirsrv/slapd-instance -L -n "name of CA cert"
certutil -d /etc/dirsrv/slapd-instance -L -n "name of server cert"
>
> ~Chris
>
> On 9/19/11 2:47 PM, Rich Megginson wrote:
>> On 09/19/2011 12:26 PM, Chris M. Ober wrote:
>>> Hello all,
>>>
>>> I've installed 389 to replace an ancient server that is on its last
>>> legs. I got everything configured and working, until just now. I
>>> generated and signed ssl keys to use ldaps, and it seemed to accept
>>> everything. It told me to restart the service, which it wouldn't
>>> allow me to do from the console. From the command line `service
>>> dirsrv restart` gave me an error I can't figure out. The error is:
>>>
>>> <?ae=PreFormAction&a=Forward&t=IPM.Note&id=RgAAAAAddcPi7ODVRL%2bRKLFJpZ86BwCjUgqOSZifQqfpcvM7EMjGAAAAkkLWAACjUgqOSZifQqfpcvM7EMjGAAAO0Wg%2fAAAJ&pspid=_1316456764395_268663948#>
>>>
>>> [root@ceto2 ~]# service dirsrv start
>>> Starting dirsrv:
>>> ceto2...[19/Sep/2011:14:07:19 -0400] - SSL alert: Security
>>> Initialization: Unable to authenticate (Netscape Portable Runtime
>>> error -8192 - An I/O error occurred during security authorization.)
>>> [19/Sep/2011:14:07:19 -0400] - ERROR: SSL Initialization Failed.
>>> [FAILED]
>>> *** Warning: 1 instance(s) failed to start
>>>
>>>
>>> I haven't been able to find anything on google to help me solve
>>> this. Any idea what is going wrong?
>> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-singl...
>>
>>>
>>>
>>> Thank you,
>>> Chris
>>>
>>>
>>> --
>>> 389 users mailing list
>>> 389-users(a)lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>
>>
12 years, 7 months
memberOf plugin case
by Vasil Mikhalenya
Hi all,
memberOf plugin changes case of it attrs.
I have to specify about 4 variants in Cisco ASA ldap map to get auth work, like
memberOf: CN=VPN-users,ou=People,dc=mydoamin
memberOf: cn=VPN-users,ou=People,dc=mydoamin
memberOf: cn=vpn-users,ou=people,dc=mydoamin
memberOf: cn=VPN-users,ou=people,dc=mydoamin
Is there any workaround?
--
Best regards,
Vasil Mikhalenya
12 years, 7 months
Will administrator set passwords expire ?
by Svein Otto Solem
When setting "passwordMustChange" to on and resetting a users password as an administrator, the users passwordExpirationTime will be set to 19700101000000Z. The user will then be prompted for a new password at first login. It seems that 19700101000000Z in passwordExpirationTime indicate that the user must change his password at next use.
How do I set that the user must change his password at first use, but if "first use" is after a year since adminstrator reset the password, the users password should have expired and been set to unusable ?
Regards Svein Otto Solem
12 years, 7 months
Replication questions.
by Reinhard Nappert
Hi, I have a multi-master setup with three masters. All of them are running 1.2.8.2. I had created and deleted the replication environment at least 3 times.
The current setup looks like the following.
Svr A has replication id 1, Srv B has the replication id 3 and Srv C has the id 4. The replication seems to work.
When I look into the dse.ldif files, I see the following:
Srv A:
dn: cn=replica,cn=o\3base,cn=mapping tree,cn=config
nsDS5ReplicaRoot: o=base
nsDS5ReplicaId: 1
nsDS5Flags: 1
nsDS5ReplicaType: 3
objectClass: top
objectClass: nsDS5Replica
cn: replica
...
nsDS5ReplicaReferral: ldap://SrvB:389/o=base
nsDS5ReplicaReferral: ldap://SrvC:389/o=base
numSubordinates: 2
dn: cn=SrvA2SrvB,cn=replica,cn=o\3base,cn=mapping tree,cn=config
objectClass: top
objectClass: nsDS5ReplicationAgreement
...
nsDS5ReplicaRoot: o=base
nsds50ruv: {replicageneration} 4e5ab509000000010000
nsds50ruv: {replica 3 ldap://SrvB:389} 4e775b74000000030000 4e77634c00000003
0000
nsds50ruv: {replica 4 ldap://SrvC:389} 4e77621d000000040000 4e77634900000
0040000
nsds50ruv: {replica 1 ldap://SrvA:389} 4e5ab517000000010000 4e77633d0000000
10000
nsds50ruv: {replica 2 ldap://SrvC:389} 4e775c9c000000020000 4e775e4c00000
0020000
nsruvReplicaLastModified: {replica 3 ldap://SrvB:389} 00000000
nsruvReplicaLastModified: {replica 4 ldap://SrvC:389} 00000000
nsruvReplicaLastModified: {replica 1 ldap://SrvA389} 00000000
nsruvReplicaLastModified: {replica 2 ldap://SrvC:389} 00000000
dn: cn=SrvA2SrvC,cn=replica,cn=o\3DUMC,cn=mapping tree,cn=config
...
nsds50ruv: {replicageneration} 4e5ab509000000010000
nsds50ruv: {replica 4 ldap://SrvC:389} 4e77621d000000040000 4e77634900000
0040000
nsds50ruv: {replica 3 ldap://SrvB:389} 4e775b74000000030000 4e77634c00000003
0000
nsds50ruv: {replica 1 ldap://SrvA:389} 4e5ab517000000010000 4e77634e0000000
10000
nsds50ruv: {replica 2 ldap://SrvC:389} 4e775c9c000000020000 4e775e4c00000
0020000
nsruvReplicaLastModified: {replica 4 ldap://SrvC:389} 00000000
nsruvReplicaLastModified: {replica 3 ldap://SrvB:389} 00000000
nsruvReplicaLastModified: {replica 1 ldap://SrvA:389} 00000000
nsruvReplicaLastModified: {replica 2 ldap://SrvC:389} 00000000
I did expect that the replicageneration is equal for all of the agreements (not only locally but also for the others).
When, I look at SrvB and SrvC, I do not seen any replicageneration: No nsds50ruv and nsruvReplicaLastModified values!
Srv B:
dn: cn=replica,cn=o\3base,cn=mapping tree,cn=config
nsDS5ReplicaRoot: o=base
nsDS5ReplicaId: 2
nsDS5Flags: 1
nsDS5ReplicaType: 3
objectClass: top
objectClass: nsDS5Replica
cn: replica
...
nsDS5ReplicaReferral: ldap://SrvA:389/o=base
nsDS5ReplicaReferral: ldap://SrvC:389/o=base
numSubordinates: 2
dn: cn=SrvB2SrvA,cn=replica,cn=o\3base,cn=mapping tree,cn=config
objectClass: top
objectClass: nsDS5ReplicationAgreement
...
nsDS5ReplicaRoot: o=base
dn: cn=SrvB2SrvC,cn=replica,cn=o\3DUMC,cn=mapping tree,cn=config
...
Srv3 entries look like:
Srv C:
dn: cn=replica,cn=o\3base,cn=mapping tree,cn=config
nsDS5ReplicaRoot: o=base
nsDS5ReplicaId: 3
nsDS5Flags: 1
nsDS5ReplicaType: 3
objectClass: top
objectClass: nsDS5Replica
cn: replica
...
nsDS5ReplicaReferral: ldap://SrvB:389/o=base
nsDS5ReplicaReferral: ldap://SrvA:389/o=base
numSubordinates: 2
dn: cn=SrvC2SrvA,cn=replica,cn=o\3base,cn=mapping tree,cn=config
objectClass: top
objectClass: nsDS5ReplicationAgreement
...
nsDS5ReplicaRoot: o=base
dn: cn=SrvC2SrvB,cn=replica,cn=o\3DUMC,cn=mapping tree,cn=config
...
So, my questions are:
Why are the two attributes nsds50ruv and nsruvReplicaLastModified missing in the agreement objects on SrvB and SrvC. Secondly, why do I still see those old values for nsds50ruv and nsruvReplicaLastModified in SrvA. This looks strange to me.
Even more confusing is that I see those attributes if I read the dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,o=base entry. Why are those nsds50ruv with old replicagenerations still there? At least the replicageneration is identical on all three boxes.
SrvA:
dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,o=base
objectClass: top
objectClass: nsTombstone
objectClass: extensibleobject
nsds50ruv: {replicageneration} 4e5ab509000000010000
nsds50ruv: {replica 4 ldap://SrvC:389} 4e77621d000000040000 4e7770f200000
0040000
nsds50ruv: {replica 3 ldap://SrvB:389} 4e775b74000000030000 4e77860b00000003
0000
nsds50ruv: {replica 1 ldap://SrvA:389} 4e5ab517000000010000 4e77859d0000000
10000
nsds50ruv: {replica 2 ldap://SrvC:389} 4e775c9c000000020000 4e775e4c00000
0020000
o: umc
nsruvReplicaLastModified: {replica 4 ldap://SrvC:389} 4e7770f1
nsruvReplicaLastModified: {replica 3 ldap://SrvB:389} 4e77860a
nsruvReplicaLastModified: {replica 1 ldap://SrvA:389} 4e77859c
nsruvReplicaLastModified: {replica 2 ldap://SrvC:389} 00000000
SrvB:
dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,o=base
objectClass: top
objectClass: nsTombstone
objectClass: extensibleobject
nsds50ruv: {replicageneration} 4e5ab509000000010000
nsds50ruv: {replica 1 ldap://SrvA:389} 4e5ab517000000010000 4e77859d0000000
10000
nsds50ruv: {replica 4 ldap://SrvC:389} 4e77621d000000040000 4e7770f200000
0040000
nsds50ruv: {replica 2 ldap://SrvC:389} 4e775c9c000000020000 4e775e4c00000
0020000
nsds50ruv: {replica 3 ldap://SrvB:389} 4e775b74000000030000 4e77860b00000003
0000
o: umc
nsruvReplicaLastModified: {replica 1 ldap://SrvA:389} 4e77859c
nsruvReplicaLastModified: {replica 4 ldap://SrvC:389} 4e7770f1
nsruvReplicaLastModified: {replica 2 ldap://SrvC:389} 00000000
nsruvReplicaLastModified: {replica 3 ldap://SrvB:389} 4e778609
SrvC:
dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,o=base
objectClass: top
objectClass: nsTombstone
objectClass: extensibleobject
nsds50ruv: {replicageneration} 4e5ab509000000010000
nsds50ruv: {replica 3 ldap://SrvB:389} 4e775b74000000030000 4e77860b00000003
0000
nsds50ruv: {replica 4 ldap://SrvC:389} 4e77621d000000040000 4e7770f200000
0040000
nsds50ruv: {replica 1 ldap://SrvA:389} 4e5ab517000000010000 4e77859d0000000
10000
nsds50ruv: {replica 2 ldap://SrvC:389} 4e775c9c000000020000 4e775e4c00000
0020000
o: umc
nsruvReplicaLastModified: {replica 3 ldap://SrvB:389} 4e77860a
nsruvReplicaLastModified: {replica 4 ldap://SrvC:389} 4e7770f1
nsruvReplicaLastModified: {replica 1 ldap://SrvA:389} 4e77859c
nsruvReplicaLastModified: {replica 2 ldap://SrvC:389} 00000000
12 years, 7 months
SSL Error on Startup
by Chris M. Ober
Hello all,
I've installed 389 to replace an ancient server that is on its last legs. I got everything configured and working, until just now. I generated and signed ssl keys to use ldaps, and it seemed to accept everything. It told me to restart the service, which it wouldn't allow me to do from the console. From the command line `service dirsrv restart` gave me an error I can't figure out. The error is:
[root@ceto2 ~]# service dirsrv start
Starting dirsrv:
ceto2...[19/Sep/2011:14:07:19 -0400] - SSL alert: Security Initialization: Unable to authenticate (Netscape Portable Runtime error -8192 - An I/O error occurred during security authorization.)
[19/Sep/2011:14:07:19 -0400] - ERROR: SSL Initialization Failed.
[FAILED]
*** Warning: 1 instance(s) failed to start
I haven't been able to find anything on google to help me solve this. Any idea what is going wrong?
Thank you,
Chris
12 years, 7 months
ad nested objects sync
by Vasil Mikhalenya
hi all,
can windows sync agreement replicate nested objects ? like
cn=user1,ou=location1,ou=Root,dc=domain ?
when i specify ou=Root,dc=domain in sync agreement - it replicates
only objects under ou=Root,dc=domain itself like
cn=user_in_root,ou=Root,dc=domain but neither
cn=user1,ou=location1,ou=Root,dc=domain nor
ou=location1,ou=Root,dc=domain
Is it possible at all?
thnx
--
Best regards,
Vasil Mikhalenya
12 years, 7 months
can't install 389-ds-base 1.2.9.9 on RHEL 6.1
by Thang Nguyen
I can't seem to install 389-ds-base 1.2.9.9 on RHEL6.1 using yum. I
follow the instructions from
http://directory.fedoraproject.org/wiki/Download by
1. Download and copy epel-389-ds-base.repo to /etc/yum.reposd
2. rpm -Uvh epel-release-6-5.noarch.rpm
When I run 'yum install 389-ds' which by default pointing to
epel-389-ds-base repo. I get selinux-policy-base conflict:
# yum install 389-ds
Loaded plugins: rhnplugin
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package 389-ds.noarch 0:1.2.2-1.el6 will be installed
--> Processing Dependency: 389-ds-console for package:
389-ds-1.2.2-1.el6.noarch
--> Processing Dependency: 389-ds-console-doc for package:
389-ds-1.2.2-1.el6.noarch
--> Processing Dependency: 389-admin-console-doc for package:
389-ds-1.2.2-1.el6.noarch
--> Processing Dependency: 389-ds-base for package:
389-ds-1.2.2-1.el6.noarch
--> Processing Dependency: 389-admin-console for package:
389-ds-1.2.2-1.el6.noarch
--> Processing Dependency: 389-admin for package: 389-ds-1.2.2-1.el6.noarch
--> Processing Dependency: 389-dsgw for package: 389-ds-1.2.2-1.el6.noarch
--> Processing Dependency: 389-console for package:
389-ds-1.2.2-1.el6.noarch
--> Running transaction check
---> Package 389-admin.x86_64 0:1.1.23-1.el6 will be installed
--> Processing Dependency: libadminutil.so.0()(64bit) for package:
389-admin-1.1.23-1.el6.x86_64
--> Processing Dependency: libadmsslutil.so.0()(64bit) for package:
389-admin-1.1.23-1.el6.x86_64
---> Package 389-admin-console.noarch 0:1.1.8-1.el6 will be installed
---> Package 389-admin-console-doc.noarch 0:1.1.8-1.el6 will be installed
---> Package 389-console.noarch 0:1.1.7-1.el6 will be installed
---> Package 389-ds-base.x86_64 0:1.2.8.3-1.el6 will be installed
--> Processing Dependency: 389-ds-base-libs = 1.2.8.3-1.el6 for package:
389-ds-base-1.2.8.3-1.el6.x86_64
--> Processing Dependency: libslapd.so.0()(64bit) for package:
389-ds-base-1.2.8.3-1.el6.x86_64
---> Package 389-ds-console.noarch 0:1.2.6-1.el6 will be installed
---> Package 389-ds-console-doc.noarch 0:1.2.6-1.el6 will be installed
---> Package 389-dsgw.x86_64 0:1.1.7-1.el6 will be installed
--> Running transaction check
---> Package 389-adminutil.x86_64 0:1.1.14-2.el6 will be installed
---> Package 389-ds-base-libs.x86_64 0:1.2.8.3-1.el6 will be installed
--> Processing Conflict: 389-ds-base-1.2.8.3-1.el6.x86_64 conflicts
selinux-policy-base < 3.9.7-11
--> Finished Dependency Resolution
Error: 389-ds-base conflicts with selinux-policy-targeted
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
It doesn't automatically install version 1.2.9.9 instead it tries to
install version 1.2.8.3.
I was able to install 389-ds-base 1.2.9.0 when pointing to
"epel-testing-389-ds-base" I can only install 389-ds-base-1.2.9.0 and
can't seem to upgrade to 1.2.9.9.
Anyone know why I can't install 389-ds-base 1.2.9.9 using yum even
though the rpm is in the epel-389-ds-base repository?
thank you.
--thang
--
12 years, 7 months
