389-users January 2011

389-users@lists.fedoraproject.org

42 participants
45 discussions

Re: [389-users] RHEL6 support
by Maurice James 26 Jan '11

26 Jan '11

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

1 0

HOW TO INSTALL NEW INTERMEDIATE CA CERTIFICATES ON 389 DS
by Tim Weichel 26 Jan '11

26 Jan '11

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-interm… 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?page=…) 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

2 1

HOW TO INSTALL NEW INTERMEDIATE CA CERTIFICATES ON 389 DS
by Tim Weichel 26 Jan '11

26 Jan '11

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?page=…) 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

2 1

Announcing 389 Directory Server 1.2.8 Alpha 1 for testing
by Rich Megginson 26 Jan '11

26 Jan '11

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_.28… 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

2 2

1.2.6.1 crash in entry_same_dn
by Balaji Ganesan 25 Jan '11

25 Jan '11

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

2 1

Determine when a password is about to expire
by harry.devine＠faa.gov 24 Jan '11

24 Jan '11

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

5 7

changelogdb getting too large
by Paulo Silva 24 Jan '11

24 Jan '11

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>

4 10

Re: [389-users] . Mapping AD names to unix
by Zebee Johnstone 24 Jan '11

24 Jan '11

>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

1 0

Re: [389-users] slapd only listening on IPv6
by Josh Ellsworth 19 Jan '11

19 Jan '11

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

2 3

Sync AD with 389-DS Unable to parse response
by remy d1 19 Jan '11

19 Jan '11

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

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users January 2011