Re: [389-users] RHEL6 support
by Maurice James
Is it not possible to use Redhat Directory Service?
<http://g.bfbcs.com/175/pc_Lt%20Loooootz.png> Description: pc_Lt Loooootz
From: 389-users-bounces(a)lists.fedoraproject.org
[mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of Aaron
Hagopian
Sent: Wednesday, January 26, 2011 2:25 PM
To: General discussion list for the 389 Directory server project.
Subject: [389-users] RHEL6 support
It looks like EPEL is now stable on RHEL6 but I do not see any 389ds
packages in the epel or epel-testing repos. Any idea when that is
happening? I'm setting up a new machine and wanted to start using RHEL6 if
possible to take advantage of some of the new fun features of RHEL6.
Thanks for all your hard work, 389ds is great!
Sincerely,
Aaron Hagopian
13 years, 2 months
HOW TO INSTALL NEW INTERMEDIATE CA CERTIFICATES ON 389 DS
by Tim Weichel
I have successfully installed the intermediate CA certificates into the cert database and no longer having an issue.
The ldap server is up and running with SSL now.
To summarize my issues and resolution:
The First issue I found was that I was not utilizing the proper intermediate certificates from VeriSign, this is based on the flavor of certificates you own.
Please be sure you are utilizing the correct intermediate certs from your CA, this can be confusing and since LDAP servers are not the main consumers
Of certificates they are not really listed. Mostly guidance for WWW servers are provided. Here is the certs I has to utilize.
http://www.verisign.com/support/verisign-intermediate-ca/secure-site-inte...
I was using the bundled certificates and not the individual Primary and Secondary certs individually.
But even after that change I was still having issues installing the certificates, here is an example error:
[root@ldap1 slapd-ldap1]# certutil -A -n VeriSign_Intermediate -t "CT,," -i /etc/dirsrv/slapd-ldap1/intermediate.crt -d /etc/dirsrv/slapd-ldap1
certutil: could not obtain certificate from file: security library: improperly formatted DER-encoded message.
The Second issue is that I suspected that I needed to recreate the database (cert8.db), I assumed it must have been corrupted in some manner.
[root@ldap1 slapd-ldap1]#certutil -N -d /etc/dirsrv/slapd-ldap1
Once I recreated the database I was able to successfully reinstall all of the certs with no issues using the following commands:
[root@ldap1 slapd-ldap1]#pk12util -i /etc/dirsrv/slapd-ldap1/ldap1cert.p12 -d .
[root@ldap1 slapd-ldap1]#certutil -A -n VeriSign_Intermediate -t "CT,," -i /etc/dirsrv/slapd-ldap1/intermediate.crt -d /etc/dirsrv/slapd-ldap1
[root@ldap1 slapd-ldap1]#certutil -A -n VeriSign_Secondary -t "CT,," -i /etc/dirsrv/slapd-ldap1/secondary.crt -d /etc/dirsrv/slapd-ldap1
The ldap server now starts with no certificate issues and binds over port 636. Hooray!!
Appreciate the response and anyone else who was contemplating my issue.
I hope this helps someone else from making the same mistake I did.................Tim
From: Tim Weichel
Sent: Tuesday, January 25, 2011 5:08 PM
To: '389-users(a)lists.fedoraproject.org'
Cc: Identitysupport
Subject: HOW TO INSTALL NEW INTERMEDIATE CA CERTIFICATES ON 389 DS
All,
I have installed 389 servers and in the process of requesting new 4 year SSL certificates for my servers. To do so Verisign is only accepting 2048-bit and higher CSR's only for 3 year certificates.
No problem I manually created a new CSR with 2048 bits using openssl, received my new cert from verisign and have installed it successfully.
Now that I have the new cert installed and SSL configured and my pin.txt file in place I find that upon start-up of the directory service the certificate will not properly verify and the startup fails.
Based on the VeriSign advisory AD220 (https://knowledge.verisign.com/support/ssl-certificates-support/index?pag...)
It appears that I need to update the directory servers VeriSign intermediate certificates in order to properly validate my new 2048 cert upon startup.
My new certificate came with the notice also as follows: In order for your VeriSign SSL Certificate to function properly, NEW Primary and Secondary VeriSign Intermediate CA Certificates must be installed.
So has anyone actually updated or installed the new primary and secondary intermediate CA certificates.
The usual methods of certutil command and the Management Console wizard have all failed to install the provided intermediate CA bundle provided by VeriSign.
Also I am not running Apache, I only have the 389 Management Console serving web for the servers.
Thanks appreciate your assistance. Love the list server you guys ROCK!.........................Tim
13 years, 2 months
HOW TO INSTALL NEW INTERMEDIATE CA CERTIFICATES ON 389 DS
by Tim Weichel
All,
I have installed 389 servers and in the process of requesting new 4 year SSL certificates for my servers. To do so Verisign is only accepting 2048-bit and higher CSR's only for 3 year certificates.
No problem I manually created a new CSR with 2048 bits using openssl, received my new cert from verisign and have installed it successfully.
Now that I have the new cert installed and SSL configured and my pin.txt file in place I find that upon start-up of the directory service the certificate will not properly verify and the startup fails.
Based on the VeriSign advisory AD220 (https://knowledge.verisign.com/support/ssl-certificates-support/index?pag...)
It appears that I need to update the directory servers VeriSign intermediate certificates in order to properly validate my new 2048 cert upon startup.
My new certificate came with the notice also as follows: In order for your VeriSign SSL Certificate to function properly, NEW Primary and Secondary VeriSign Intermediate CA Certificates must be installed.
So has anyone actually updated or installed the new primary and secondary intermediate CA certificates.
The usual methods of certutil command and the Management Console wizard have all failed to install the provided intermediate CA bundle provided by VeriSign.
Also I am not running Apache, I only have the 389 Management Console serving web for the servers.
Thanks appreciate your assistance. Love the list server you guys ROCK!.........................Tim
13 years, 2 months
Announcing 389 Directory Server 1.2.8 Alpha 1 for testing
by Rich Megginson
The 389 team is pleased to announce the availability for testing of
Alpha 1 of version 1.2.8. This release contains many bug fixes. On
those platforms which have OpenLDAP built with Mozilla NSS crypto
support (Fedora 14 and later), the packages are built with OpenLDAP
instead of the Mozilla LDAP C SDK.
WARNING: If you are upgrading from a previous 1.2.6 release candidate,
you will need to run fixfiles to fix some SELinux AVCs, or directory
server will not start. See bug
https://bugzilla.redhat.com/show_bug.cgi?id=622882
To fix, run this:
fixfiles -R 389-ds-base restore
If you are upgrading from 1.2.5 or earlier, or a stable 1.2.6 or 1.2.7,
there is no problem.
WARNING: If you are upgrading from a 1.2.6 alpha or release candidate,
you will need to manually fix your entryrdn index files. See
http://port389.org/wiki/Subtree_Rename#warning:_upgrade_from_389_v1.2.6_....
for more information. If you are upgrading from 1.2.5 or earlier, or a
1.2.6 or 1.2.7 stable release, there is no problem.
The new packages and versions are:
* 389-ds-base 1.2.8.a1
***We need your help! Please help us test this software.*** It is an
Alpha release, so it may have a few glitches, but it has been tested for
regressions and for new feature bugs. The Fedora system
requires that packages go into Testing until verified and pushed
to Stable.
The more testing we get, the faster we can release these packages to
Stable. See the Release Notes for information about how to provide
testing feedback (or just send an email to
389-users(a)lists.fedoraproject.org).
=== Installation ===
yum install --enablerepo=[updates-testing|epel-testing] 389-ds
setup-ds-admin.pl
=== Upgrade ===
yum upgrade --enablerepo=[updates-testing|epel-testing] 389-ds-base
setup-ds-admin.pl -u
=== Bugs Fixed ===
This release contains many bug fixes. The complete list of bugs
fixed is found at the link below. Note that bugs marked as MODIFIED
have been fixed but are still in testing.
* Bug List for 389 1.2.8
https://bugzilla.redhat.com/showdependencytree.cgi?id=656390&hide_resolved=0
* Release Notes - http://port389.org/wiki/Release_Notes
* Install_Guide - http://port389.org/wiki/Install_Guide
* Download - http://port389.org/wiki/Download
13 years, 2 months
1.2.6.1 crash in entry_same_dn
by Balaji Ganesan
Hi All - We upgraded our system to 1.2.6.1 from 1.2.5 ~40 days ago
(RH5.4, 64bit ). Things were running fine till saturday, when one of
the nodes crashed. We are running MMR with ~6million users. Quick
search of buglist shows that similar issues have already been fixed.
Backtrace is below. Any ideas? I don't have access/error logs, they
got rotated. Thanks in advance.
----
#0 0x00000039474787d0 in strcmp () from /lib64/libc.so.6
(gdb) bt
#0 0x00000039474787d0 in strcmp () from /lib64/libc.so.6
#1 0x00002b335804337c in entry_same_dn (e=<value optimized out>,
k=0x2aabd2f697b0) at ldap/servers/slapd/back-ldbm/cache.c:169
#2 0x00002b3358042233 in remove_hash (ht=0x1bdd1f20, key=0x2aabd2f697b0,
keylen=<value optimized out>) at ldap/servers/slapd/back-ldbm/cache.c:262
#3 0x00002b3358042961 in entrycache_remove_int (cache=0x1bd4d138,
e=0x2aabb1964ed0) at ldap/servers/slapd/back-ldbm/cache.c:817
#4 0x00002b3358042a53 in entrycache_flush (cache=0x1bd4d138)
at ldap/servers/slapd/back-ldbm/cache.c:544
#5 0x00002b3358042ce3 in entrycache_add_int (cache=0x1bd4d138,
e=0x2aaae8b827f0, state=0, alt=<value optimized out>)
at ldap/servers/slapd/back-ldbm/cache.c:1322
#6 0x00002b3358042ecc in cache_add (cache=0x1bd4d138, ptr=0x2aabd2f697b0,
alt=0x5af91188) at ldap/servers/slapd/back-ldbm/cache.c:1357
#7 0x00002b33580515d0 in id2entry (be=0x1bd4c330, id=1526272384, txn=0x0,
err=<value optimized out>) at ldap/servers/slapd/back-ldbm/id2entry.c:437
#8 0x00002b335807d6ed in ldbm_back_next_search_entry_ext (pb=0x27d10640,
use_extension=0) at ldap/servers/slapd/back-ldbm/ldbm_search.c:1246
#9 0x00002b3352d9b931 in iterate (pb=0x27d10640, be=0x1bd4c330,
send_result=1, pnentries=0x5af97f54, pagesize=-1, pr_statp=0x5af97f48)
at ldap/servers/slapd/opshared.c:1088
#10 0x00002b3352d9be62 in send_results_ext (pb=0x27d10640, send_result=1,
nentries=0x5af97f54, pagesize=-1, pr_stat=0x5af97f48)
at ldap/servers/slapd/opshared.c:1473
#11 0x00002b3352d9c7b5 in op_shared_search (pb=0x27d10640, send_result=1)
at ldap/servers/slapd/opshared.c:688
#12 0x00002b3352da6a34 in search_internal_callback_pb (pb=0x27d10640,
callback_data=0x5af9a070, prc=<value optimized out>,
psec=<value optimized out>, prec=0)
at ldap/servers/slapd/plugin_internal_op.c:761
#13 0x00002b33585b2fe6 in _replica_reap_tombstones (arg=<value optimized out>)
at ldap/servers/plugins/replication/repl5_replica.c:2526
#14 0x00002b335477ff7d in _pt_root () from /opt/dirsrv/lib/libnspr4.so
#15 0x0000003947c06367 in start_thread () from /lib64/libpthread.so.0
#16 0x00000039474d30ad in clone () from /lib64/libc.so.6
13 years, 2 months
Determine when a password is about to expire
by harry.devine＠faa.gov
I am in the process of creating a web-based mechanism to allow our users
to change their password on our new 389-ds server. I would like to
display the date that their password is due to expire, and while Googling
around, I see a lot of references to pwdLastSet, but about 95% of the
articles are referring to Active Directory. I don't see pwdLastSet
amongst the attributes in my default 389-ds setup. Is it there, or do I
have to add that attribute to every account?
Also, I currently have my pages set up where, when the user logs in, it
detects our 'default' password and forces them to change it. Is there
some attribute in their account that I can set that I can key off of and
force them to change their password when they login to my site?
Thanks for any tips!
Harry
Harry Devine
Common ARTS Software Development
AJT-144
(609)485-4218
Harry.Devine(a)faa.gov
13 years, 2 months
changelogdb getting too large
by Paulo Silva
Hi,
I have a Multimaster replication setup with 3 servers and I've noticed that
the changelogdb dir has some very large files:
# ls -lha changelogdb/
total 8.2G
drwx------ 2 nobody nobody 4.0K Jan 18 20:32 .
drwxr-x--- 6 nobody nobody 4.0K Jan 18 15:23 ..
-rw------- 1 nobody nobody 0 Jan 18 18:01
5b261e84-fe7011dd-a1f9862f-16c3237d.sema
-rw------- 1 nobody nobody 8.2G Jan 18 20:43
5b261e84-fe7011dd-a1f9862f-16c3237d_499c5871000000010000.db4
-rw------- 1 nobody nobody 30 Feb 18 2009 DBVERSION
-rw------- 1 nobody nobody 24K Aug 14 20:35 __db.001
-rw------- 1 nobody nobody 13M Aug 14 20:35 __db.002
-rw------- 1 nobody nobody 96K Aug 14 20:35 __db.003
-rw------- 1 nobody nobody 648K Aug 14 20:35 __db.004
-rw------- 1 nobody nobody 56K Aug 14 20:35 __db.005
-rw------- 1 nobody nobody 10M Jan 18 20:44 log.0000007060
Is there any way to reduce it's size?
Thanks
--
Paulo Silva <paulojjs(a)gmail.com>
13 years, 2 months
Re: [389-users] . Mapping AD names to unix
by Zebee Johnstone
>Date: Fri, 21 Jan 2011 09:49:09 +0100
>From: Carsten Grzemba <grzemba(a)contac-dt.de>
>Yes, directory servers winsync maps AD's samAccountName to uid on LDAP-DS, and Unix use >the uid attribute for login name. It is not necessary to use kerberos authentication of >AD, if you sync passwords between AD and DS with winsync.
Thank you very much for that.
Zebee
13 years, 2 months
Re: [389-users] slapd only listening on IPv6
by Josh Ellsworth
I don't see any errors - looks like the admin server is starting up? If
you do a service dirsrv-admin start or restart (while the directory
server is running) do you get an error? Does ps -ef|grep httpd show 3
processes?
I'm sorry that I was not more clear. Nsslapd seems to only be listening
on ipv6 so the admin server never starts. After rebooting the server I
ran service dirsrv start. Running service dirsrv-admin start resulted
in Starting dirsrv-admin: appearing on the screen with no 'OK' for at
least an hour, after which I cancelled the command with ^z. Subsequent
investigations led me to believe that the cause was nsslapd only
listening on ipv6.
From: Rich Megginson [mailto:rmeggins@redhat.com]
Sent: Wednesday, January 19, 2011 1:52 PM
To: Ellsworth, Josh
Subject: Re: [389-users] slapd only listening on IPv6
On 01/19/2011 10:23 AM, Ellsworth, Josh wrote:
OK, I think I have all of these answered.
Can you post the error log from /var/log/dirsrv/admin-serv/error?
[Tue Jan 18 16:28:40 2011] [info] done Init: Initializing NSS library
[Tue Jan 18 16:28:40 2011] [debug] mod_admserv/mod_admserv.c(220):
HashTableEnumerate: Key=admin-serv Val=cn=admin-serv-ldaptest,cn=389
Administration Server,cn=Server
Group,cn=ldaptest.illuminatics.local,ou=illuminatics.local,o=NetscapeRoo
t
[Tue Jan 18 16:28:40 2011] [debug] mod_admserv/mod_admserv.c(1444):
populate_tasks_from_server(): getting tasks for server [admin-serv]
siedn [cn=admin-serv-ldaptest,cn=389 Administration Server,cn=Server
Group,cn=ldaptest.illuminatics.local,ou=illuminatics.local,o=NetscapeRoo
t]
[Tue Jan 18 16:28:40 2011] [notice] Access Host filter is:
*.illuminatics.local
[Tue Jan 18 16:28:40 2011] [notice] Access Address filter is: *
[Tue Jan 18 16:28:40 2011] [error] NSS_Shutdown failed: -8038
[Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module
authz_host_module
[Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module
auth_basic_module
[Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module
authn_file_module
[Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module
log_config_module
[Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module
env_module
[Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module
mime_magic_module
[Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module
expires_module
[Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module
deflate_module
[Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module
headers_module
[Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module
unique_id_module
[Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module
setenvif_module
[Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module
mime_module
[Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module
vhost_alias_module
[Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module
negotiation_module
[Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module
dir_module
[Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module
actions_module
[Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module
alias_module
[Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module
rewrite_module
[Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module
cache_module
[Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module
disk_cache_module
[Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module
cgi_module
[Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module
restartd_module
[Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module
nss_module
[Tue Jan 18 16:28:40 2011] [debug] mod_so.c(246): loaded module
admserv_module
[Tue Jan 18 16:28:40 2011] [debug] mod_admserv/mod_admserv.c(2501):
[1792] create_server_config [0xbogus %p for (null)
[Tue Jan 18 16:28:40 2011] [debug] mod_admserv/mod_admserv.c(2489):
[1792] create_config [0xbogus %p for (null)
[Tue Jan 18 16:28:40 2011] [info] done Init: Initializing NSS library
[Tue Jan 18 16:28:41 2011] [notice] Apache/2.2 configured -- resuming
normal operations
[Tue Jan 18 16:37:59 2011] [warn] child process 1797 still did not exit,
sending a SIGTERM
[Tue Jan 18 16:38:00 2011] [notice] caught SIGTERM, shutting do
What platform?
[root@ldaptest ~]# uname -a
Linux ldaptest 2.6.18-194.17.4.el5xen #1 SMP Mon Oct 25 16:36:31 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux
What versions of 389-ds-base and 389-admin?
[root@ldaptest ~]# yum list | grep 389
389-admin.x86_64 1.1.13-1.el5
installed
389-admin.x86_64 1.1.14-1.el5
installed
389-admin-console.noarch 1.1.5-1.el5
installed
389-admin-console-doc.noarch 1.1.5-1.el5
installed
389-adminutil.x86_64 1.1.8-4.el5
installed
389-adminutil.x86_64 1.1.13-1.el5
installed
389-console.noarch 1.1.4-1.el5
installed
389-ds.noarch 1.2.1-1.el5
installed
389-ds-base.x86_64 1.2.7.5-1.el5
installed
389-ds-console.noarch 1.2.3-1.el5
installed
389-ds-console-doc.noarch 1.2.3-1.el5
installed
389-dsgw.x86_64 1.1.5-1.el5
installed
389-dsgw.x86_64 1.1.6-1.el5
installed
Running 'grep nsslapd-listenhost
/etc/dirsrv/slapd-INSTANCENAME/dse.ldif' (with no quotes of course) does
not return anything.
I don't see any errors - looks like the admin server is starting up? If
you do a service dirsrv-admin start or restart (while the directory
server is running) do you get an error? Does ps -ef|grep httpd show 3
processes?
From: Rich Megginson [mailto:rmeggins@redhat.com]
Sent: Wednesday, January 19, 2011 10:32 AM
To: General discussion list for the 389 Directory server project.
Cc: Ellsworth, Josh
Subject: Re: [389-users] slapd only listening on IPv6
On 01/19/2011 07:11 AM, Ellsworth, Josh wrote:
I am working on a test 389DS instance and yesterday it started giving me
trouble. The admin server would not start up correctly.
Can you post the error log from /var/log/dirsrv/admin-serv/error?
What platform? What versions of 389-ds-base and 389-admin?
I think that the problem is because slapd is not listening on IPv4.
grep nsslapd-listenhost /etc/dirsrv/slapd-INSTANCENAME/dse.ldif
[root@ldaptest ~]# netstat -aunt
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address
State
tcp 0 0 0.0.0.0:873
0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:111
0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:631
0.0.0.0:* LISTEN
tcp 0 0 :::389
:::* LISTEN
tcp 0 0 :::22
:::* LISTEN
tcp 0 0 :::636
:::* LISTEN
tcp 0 0 ::ffff:192.168.115.100:22
::ffff:192.168.150.117:1268 ESTABLISHED
udp 0 0 0.0.0.0:867
0.0.0.0:*
udp 0 0 0.0.0.0:870
0.0.0.0:*
udp 0 0 0.0.0.0:5353
0.0.0.0:*
udp 0 0 0.0.0.0:111
0.0.0.0:*
udp 0 0 0.0.0.0:631
0.0.0.0:*
udp 0 0 0.0.0.0:47870
0.0.0.0:*
udp 0 0 :::35392
:::*
udp 0 0 :::5353
:::*
[root@ldaptest ~]# lsof -i
COMMAND PID USER FD TYPE DEVICE
SIZE NODE NAME
portmap 1084 rpc 3u IPv4
2955 UDP *:sunrpc
portmap 1084 rpc 4u IPv4
2956 TCP *:sunrpc (LISTEN)
rpc.statd 1115 rpcuser 3u IPv4
3072 UDP *:870
rpc.statd 1115 rpcuser 6u IPv4
3058 UDP *:867
rpc.statd 1115 rpcuser 7u IPv4
3075 TCP *:rsync (LISTEN)
sshd 1385 root 3u
IPv6 3955 TCP *:ssh (LISTEN)
cupsd 1393 root 4u IPv4
3987 TCP localhost.localdomain:ipp (LISTEN)
cupsd 1393 root 6u IPv4
3990 UDP *:ipp
avahi-dae 1467 avahi 13u IPv4
4197 UDP *:mdns
avahi-dae 1467 avahi 14u IPv6
4198 UDP *:mdns
avahi-dae 1467 avahi 15u IPv4
4199 UDP *:47870
avahi-dae 1467 avahi 16u IPv6
4200 UDP *:35392
ns-slapd 1616 nobody 6u IPv6 4476
TCP *:ldap (LISTEN)
ns-slapd 1616 nobody 7u IPv6 4477
TCP *:ldaps (LISTEN)
Is there an easy way to fix this? Since it is a test server I _could_
wipe it and start over, but I don't want this to be a problem when we
move to production.
Thanks!
Josh
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
13 years, 3 months
Sync AD with 389-DS Unable to parse response
by remy d1
Hi,
I have some problems to synchronize 389-DS with AD
I have followed this HowTo :
http://www.linuxmail.info/389-directory-active-directory-ssl-synch/
I have successfully imported cert files in both AD and 389-DS and can
communicate in SSL mode (ldaps). I can login from my 389-DS to my AD server
with 389-console or Apache Directory Studio, but synchronize does not work.
Here are the error logs from 389-DS :
[19/Jan/2011:14:37:07 +0100] NSMMReplicationPlugin - agmt="cn=Synchro ldap"
(WINSERVER:636): Unable to parse the response to the startReplication
extended operation. Replication is aborting.
[19/Jan/2011:14:37:07 +0100] NSMMReplicationPlugin - agmt="cn=Synchro ldap"
(WINSERVER:636): Incremental update failed and requires administrator action
If I try an ldapsearch :
/usr/lib64/mozldap/ldapsearch -ZZ -b "dc=mydomain,dc=com" -h WINSERVER -p
636 -R -D "CN=synchro ldap,CN=Users,DC=mydomain,DC=com" -w - "objectclass=*"
Enter bind password:
ldap_start_tls_s failed: (Can't contact LDAP server)
ldap_simple_bind: Can't contact LDAP server
TLS/SSL error -5961 (TCP connection reset by peer.)
I have open the ports 88, 389 and 636. Should I open all this ports ? :
http://technet.microsoft.com/fr-fr/library/bb967329.aspx
Any idea ?
-Regards
13 years, 3 months
