389-users July 2013

389-users@lists.fedoraproject.org

33 participants
28 discussions

Re: [389-users] Removing non-existent instances
by Rich Megginson 29 Jul '13

29 Jul '13

On 07/29/2013 09:52 AM, Tripp Holden wrote: > They need to be removed from both the replication topology and the > console as none of the configuration was removed prior to the servers > being brought offline. For console, you can use the console to remove the instances - in the topology view, right-click on the server instance, and select Remove. For replication, you'll have to remove all of the replication agreements on other servers that point to the server you removed, then you'll have to run the CLEANALLRUV task to clean up any remaining meta-data. https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server… > > -Tripp > > > On Mon, Jul 29, 2013 at 10:47 AM, Rich Megginson <rmeggins(a)redhat.com > <mailto:rmeggins@redhat.com>> wrote: > > On 07/29/2013 09:46 AM, Tripp Holden wrote: >> Hi guys, >> >> First time posting here. I recently inherited a 389 environment >> where two servers were taken down when we moved out of a >> datacenter and were not properly removed from the directory >> configuration prior to their removal. I've read through the >> remove-ds documentation and it seems to indicate that the command >> needs to be run from the instance server that is to be removed. >> Is there a recommended method for removing non-existent instances? > > Removing them from where? From the replication topology? From the > console? > >> >> Thanks! >> -Tripp > >

1 0

adding or changing Manager
by Justin Edmands 26 Jul '13

26 Jul '13

Hey, I changed my cn=Directory Manager account to just be cn=Manager. This works and all, but I need to replicate something similar to our older openldap setup. I would like to have cn=Manager,dc=somewebsite,dc=com to allow our older website code to continue operating without modifications. Can I have: cn=Manager -and- cn=Manager,dc=somewebsite,dc=com with the same permissions and so on?

1 0

Manual & help step by step
by husam.shabeeb 22 Jul '13

22 Jul '13

Dear friends, Anyone can help me ? I have install the directory , on centos I want to make certs and install it on the server I have tried many ways but all not working , one way with p12 , when uploading the certificates it's both appear in the server tab even the CA . The other way with openssl in this case I can't upload the certificate on server tab its only appear on the CA tab . Also I want some help setting Acyls Like I want to have many admins each one can control his group no access for the other groups Many thanks in advance .

3 17

389 Deadlock
by Jeffrey Dunham 22 Jul '13

22 Jul '13

Hello, Starting a day ago we have been noticing deadlocks on select 389 servers. It does not happen on all of them (10% of servers have been affected currently, and no repeat offenders). Just looking for any hints on where to look or what could be causing this issue. Version: 389-Directory/1.2.10.14 >From GDB: 0x00002b0df2847654 in __lll_lock_wait () from /lib64/libpthread.so.0 (gdb) info threads 40 Thread 0x2b0e86c91940 (LWP 10689) 0x00002b0df2b24122 in select () from /lib64/libc.so.6 39 Thread 0x2b0e87692940 (LWP 10690) 0x00002b0df2b24122 in select () from /lib64/libc.so.6 38 Thread 0x2b0e88093940 (LWP 10691) 0x00002b0df2b24122 in select () from /lib64/libc.so.6 37 Thread 0x2b0e88a94940 (LWP 10692) 0x00002b0df2b24122 in select () from /lib64/libc.so.6 36 Thread 0x2b0e89495940 (LWP 10734) 0x00002b0df2845019 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 35 Thread 0x2b0e89e96940 (LWP 10735) 0x00002b0df2845019 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 34 Thread 0x2b0e8a897940 (LWP 10736) 0x00002b0df2845280 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 33 Thread 0x2b0e8b298940 (LWP 10737) 0x00002b0df2845280 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 32 Thread 0x2b0e91f00940 (LWP 10738) 0x00002b0df2845280 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 31 Thread 0x2b0e92901940 (LWP 10739) 0x00002b0df2847654 in __lll_lock_wait () from /lib64/libpthread.so.0 30 Thread 0x2b0e93302940 (LWP 10740) 0x00002b0df2845280 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 29 Thread 0x2b0e93d03940 (LWP 10741) 0x00002b0df2845280 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 28 Thread 0x2b0e94704940 (LWP 10742) 0x00002b0df2845280 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 27 Thread 0x2b0e95105940 (LWP 10743) 0x00002b0df2845280 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 26 Thread 0x2b0e95b06940 (LWP 10744) 0x00002b0df2845280 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 25 Thread 0x2b0e96507940 (LWP 10745) 0x00002b0df2845280 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 24 Thread 0x2b0e96f08940 (LWP 10746) 0x00002b0df2845280 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 23 Thread 0x2b0e97909940 (LWP 10747) 0x00002b0df2845280 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 22 Thread 0x2b0e9830a940 (LWP 10748) 0x00002b0df2845280 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 21 Thread 0x2b0e98d0b940 (LWP 10749) 0x00002b0df2845280 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 20 Thread 0x2b0e9970c940 (LWP 10750) 0x00002b0df2845280 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 19 Thread 0x2b0e9a10d940 (LWP 10751) 0x00002b0df2845280 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 18 Thread 0x2b0e9ab0e940 (LWP 10752) 0x00002b0df2845280 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 17 Thread 0x2b0e9b50f940 (LWP 10753) 0x00002b0df2845280 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 16 Thread 0x2b0e9bf10940 (LWP 10754) 0x00002b0df2845280 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 15 Thread 0x2b0e9c911940 (LWP 10755) 0x00002b0df2845280 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 14 Thread 0x2b0e9d312940 (LWP 10756) 0x00002b0df2845280 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 13 Thread 0x2b0e9dd13940 (LWP 10757) 0x00002b0df2845280 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 12 Thread 0x2b0e9e714940 (LWP 10758) 0x00002b0df2845280 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 11 Thread 0x2b0e9f115940 (LWP 10759) 0x00002b0df2845280 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 10 Thread 0x2b0e9fb16940 (LWP 10760) 0x00002b0df2845280 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 9 Thread 0x2b0ea0517940 (LWP 10761) 0x00002b0df2845280 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 8 Thread 0x2b0ea0f18940 (LWP 10762) 0x00002b0df2845280 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 7 Thread 0x2b0ea1919940 (LWP 10763) 0x00002b0df2845280 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 6 Thread 0x2b0ea231a940 (LWP 10764) 0x00002b0df2845280 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 5 Thread 0x2b0ea2d1b940 (LWP 10765) 0x00002b0df2845280 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 4 Thread 0x2b0ea371c940 (LWP 10766) 0x00002b0df2845280 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 3 Thread 0x2b0ea411d940 (LWP 10767) 0x00002b0df2845280 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 2 Thread 0x2b0ea4b1e940 (LWP 10768) 0x00002b0df2b24122 in select () from /lib64/libc.so.6 * 1 Thread 0x2b0df452a7e0 (LWP 10666) 0x00002b0df2847654 in __lll_lock_wait () from /lib64/libpthread.so.0 (gdb) bt #0 0x00002b0df2847654 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x00002b0df2842f80 in _L_lock_1233 () from /lib64/libpthread.so.0 #2 0x00002b0df2842f03 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00002b0df2204289 in PR_Lock () from /usr/lib64/libnspr4.so #4 0x0000000000415955 in ber_sockbuf_free () #5 0x00000000004166f1 in ber_sockbuf_free () #6 0x000000000041d7d4 in ?? () #7 0x00002b0df2a739c4 in __libc_start_main () from /lib64/libc.so.6 #8 0x000000000040c9b9 in ber_sockbuf_free () #9 0x00007fff5cd57a98 in ?? () #10 0x0000000000000000 in ?? ()

3 7

Fwd: Some cipher suites not working
by Darcy Hodgson 19 Jul '13

19 Jul '13

Hello, I have been setting up SSL/TLS with 389 DS on CentOS 6.4. I have been able to get it working and can connect with LDAPS. However when I started to disabled some of the ciphers I noticed that my server wasn't accepting any of the DHE ciphers. I enabled all the ciphers with +all and used sslmap to confirm that the server was only choosing RSA. I checked the logs and the only thing they say is "Cannot communicate securely with peer: no common encryption algorithm(s)." Any help getting the DHE ciphers to work or pointing me to some documentation would be appreciated. Thanks, Darcy

3 7

winsync: differences between 1.2.11.15 and 1.3
by Juan Carlos Camargo 19 Jul '13

19 Jul '13

Hi 389ers, I have a lab scenario with one server running version 1.3 on Fedora19. My production servers still use 1.2.11.15 and run on CentOS. I've created oneway sync agreements FROM Windows2003 , in both cases with the same params: windows sync user, windows host, ds subtree and windows subtree. But I've noticed that in version 1.3 sync does not work, all users are reported to be "out of scope" even when the same sAMAccountName/uid is found. Ex: v1.3 " [18/Jul/2013:12:59:15 +0200] NSMMReplicationPlugin - agmt="cn=ad5" (ad5:389): windows_process_dirsync_entry: windows inbound entry CN=XXXX has the same name as local entry uid=XXXX but the windows entry is out of the scope of the sync subtree [dc=DOMAIN] - if you want these entries to be in sync, add the ntUser/ntGroup objectclass and required attributes to the local entry, and move the windows entry into scope " v1.2.11.15 [18/Jul/2013:13:31:00 +0200] NSMMReplicationPlugin - agmt="cn=ad5" (ad5:389): map_entry_dn_inbound: looking for local entry matching AD entry [CN=XXXX] [18/Jul/2013:13:31:00 +0200] NSMMReplicationPlugin - agmt="cn=ad5" (ad5:389): map_entry_dn_inbound: looking for local entry by guid [155e86afca9f2141af71624d7f55a44c] [18/Jul/2013:13:31:00 +0200] NSMMReplicationPlugin - agmt="cn=ad5" (ad5:389): map_entry_dn_inbound: found local entry [uid=XXXX] Sorry about the different timestamps, but the user under XXXX was the same in both cases. So, same agreement in version 1.2.11.15 syncs the users (from Windows always) perfectly. I've deleted and recreated the agreements in both sides, just in case I mispelled something,but still the same results. What has changed , or better, where did I go wrong? Regards! -- Juan Carlos Camargo Carrillo. @jcarloscamargo 957-211157 , 650932877

2 3

Error when starting dirsrv after enabling SSL and installing keys and certificates
by Kyle Johnson 17 Jul '13

17 Jul '13

Hello everyone, I have been receiving help from richm in the #389 channel for the last few days, but haven't made much progress, so I'd like to move the conversation somewhere a little more persistent. My issue is that after manually enabling SSL by following the instructions at ry.fedoraproject.org/wiki/Howto:SSL#Starting_the_Server_with_SSL_enabled (that is, not using the setupssl2.sh script) and installing my CA and public and private key bundle, I am receiving the following error when starting dirsrv. I also receive this error if I run the setupssl2.sh script and then replace the certificates and keys generated by it with the ones below. [root@ldap005 slapd-ldap005]# service dirsrv restart Shutting down dirsrv: ldap005... [ OK ] Starting dirsrv: ldap005...[17/Jul/2013:14:41:21 +0000] - SSL alert: CERT_VerifyCertificateNow: verify certificate failed for cert ldap005.infra.dfw of family cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8016 - unknown) [ OK ] [root@ldap005 slapd-ldap005]# Here is a list of the installed certs: ca001.zhv.domain.com CT,, ldap005.infra.dfw u,u,u And the installed keys: < 0> rsa a25fae676b83cfeb52d1fdc671aa74a34ef4ee8c ldap005.infra.dfw My versions of 389 are as follows: 389-ds-console-1.2.6-1.el6.noarch 389-ds-1.2.2-1.el6.noarch 389-ds-base-1.2.11.15-14.el6_4.x86_64 389-admin-console-1.1.8-1.el6.noarch 389-ds-console-doc-1.2.6-1.el6.noarch 389-dsgw-1.1.9-1.el6.x86_64 389-adminutil-1.1.15-1.el6.x86_64 389-ds-base-libs-1.2.11.15-14.el6_4.x86_64 389-console-1.1.7-1.el6.noarch 389-admin-1.1.29-1.el6.x86_64 389-admin-console-doc-1.1.8-1.el6.noarch I would like to note that I have this working on another of my 389 servers, the difference being that 389-ds-base is an earlier version: 389-console-1.1.7-1.el6.noarch 389-ds-base-1.2.10.2-20.el6_3.x86_64 389-admin-console-1.1.8-1.el6.noarch 389-ds-console-doc-1.2.6-1.el6.noarch 389-dsgw-1.1.9-1.el6.x86_64 389-adminutil-1.1.15-1.el6.x86_64 389-ds-base-libs-1.2.10.2-20.el6_3.x86_64 389-admin-1.1.29-1.el6.x86_64 389-ds-console-1.2.6-1.el6.noarch 389-admin-console-doc-1.1.8-1.el6.noarch 389-ds-1.2.2-1.el6.noarch Please let me know what other information you would need to help me with troubleshooting this issue. Kyle Johnson

2 8

Re: [389-users] Authentication method not supported
by Carsten Grzemba 16 Jul '13

16 Jul '13

Am 15.07.13 schrieb Rich Megginson <rmeggins(a)redhat.com>: > > > > > > On 07/14/2013 11:00 PM, Paul Robert Marino wrote: > > > > Solaris was one of the original platforms and has been both 64 bit space and AMD along with 32 bit Intel and IBM Power arc since long ago so I find your assertion somewhat doubtful. On the other hand how can you expect a desk top 32 bit (workstation version of the IBM power) architecture which was abandoned nearly a decade ago to still be supported. > > > > Part/all of the problem may be the support for atomic operations we added a couple of years ago, which is very architecture specific, and got practically no testing on platforms other than intel/amd. So please file tickets, but what we really need is someone who can build/test on these other architectures. > > > > We can test Solaris sparc on OpenCSW buildfarm. I have already create build recipies for packaging the the 389DS build on Solaris10, Solaris11 is also possible. > > > > > > > > > > > > > > -- Sent from my HP Pre3 > > > > On Jul 14, 2013 10:38 PM, ilmir(a)atacom.kz <ilmir(a)atacom.kz> <ilmir(a)atacom.kz> wrote: > > > > Yes I think so. > > But unfortunately I can't check it. > > Becase the Fedora didn't supported ppc32 on Power Platform. > > Do you think this is a bug? I can create the bug in bugzilla. > > > > -- > > Ilmir Mulyukov > > Pre-sales Manager & Solution Designer > > Hitachi Data Systems & IBM & Juniper Networks Official Distributor > > ATACOM LTD > > Kazakhstan, Almaty > > 67, Mametovoi street, > > Tel: +7 727 237 98 97 > > Fax: +7 727 237 98 99 > > Mob: +7 701 783 40 91 > > Web: http://www.atacom.kz > > > > > > > > > > From: Ludwig Krispenz <lkrispen(a)redhat.com> <lkrispen(a)redhat.com> > > To: "General discussion list for the 389 Directory server project." <389-users(a)lists.fedoraproject.org> <389-users(a)lists.fedoraproject.org>, > > Date: 01.07.2013 20:42 > > Subject: Re: [389-users] Authentication method not supported > > Sent by: 389-users-bounces(a)lists.fedoraproject.org > > > > > > > > Hi, > > > > there was recently an other thread about a failure on sparc, now ppc, both big endian. Maybe we have a 32 access to a 64 bit var, which has no effect on little endian machines. > > > > Ludwig > > > > On 07/01/2013 04:06 PM, Rich Megginson wrote: > > On 06/30/2013 12:10 AM, ilmir(a)atacom.kz wrote: > > Good morning! > > Yes. Accesslog level is 772: > > > > [30/Jun/2013:12:00:31 +0600] conn=50705 fd=69 slot=69 connection from 127.0.0.1 to 127.0.0.1 > > [30/Jun/2013:12:00:31 +0600] conn=50705 op=0 BIND dn="uid=kolab-service,ou=Special Users,dc=example,dc=kz" method=128 version=3 > > [30/Jun/2013:12:00:31 +0600] conn=Internal op=-1 SRCH base="uid=kolab-service,ou=special users,dc=example,dc=kz" scope=0 filter="(|(objectclass=*)(objectclass=ldapsubentry))" attrs=ALL > > [30/Jun/2013:12:00:31 +0600] conn=Internal op=-1 ENTRY dn="uid=kolab-service,ou=Special Users,dc=example,dc=kz" > > [30/Jun/2013:12:00:31 +0600] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 > > [30/Jun/2013:12:00:31 +0600] conn=50705 op=0 RESULT err=7 tag=97 nentries=0 etime=0 > > [30/Jun/2013:12:00:31 +0600] conn=50705 op=1 UNBIND > > [30/Jun/2013:12:00:31 +0600] conn=50705 op=1 fd=69 closed - U1 > > > > This is part of log which is responsible for [root@xat noarch]# ldapsearch -x -D "uid=kolab-service,ou=Special Users,dc=example,dc=kz" -w secret -b "dc=example,dc=kz" -s sub "(objectclass=*)" > > > > If you need full log I can send you but it very heavy. > > > > Hmm - PPC - we don't do any testing on that platform, so it could be PPC specific. > > > > What's in the errors log? > > > > > > Thank you for helping! > > > > -- > > Ilmir Mulyukov > > > > > > > > > > From: Tim Cambridge <tim.cambridge(a)london.gov.uk> > > To: "'389-users(a)lists.fedoraproject.org'" <389-users(a)lists.fedoraproject.org>, > > Date: 30.06.2013 04:59 > > Subject: Re: [389-users] Authentication method not supported > > Sent by: 389-users-bounces(a)lists.fedoraproject.org > > > > > > > > Would it be any help to look at the access log on the server with 389-ds installed ? > > > > Maybe in sub directory of /var/log/ ? > > > > Tim > > > > From: ilmir(a)atacom.kz [mailto:ilmir@atacom.kz] > > Sent: Saturday, June 29, 2013 08:58 PM > > To: 389-users(a)lists.fedoraproject.org <389-users(a)lists.fedoraproject.org> > > Subject: [389-users] Authentication method not supported > > > > Hello! > > During the setup the Kolab on system with 389-ds I have found the following message: > > > > Your new DS instance 'xat' was successfully created. > > Creating the configuration directory server . . . > > Could not authenticate as user 'uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot' to server 'ldap://xat.example.kz:389/o=NetscapeRoot'. Error: Authentication method not supported > > > > I thought that may be this is bug of kolab but new instance have the same problem. > > > > [root@xat noarch]# ldapsearch -x -D "uid=kolab-service,ou=Special Users,dc=example,dc=kz" -w secret -b "dc=example,dc=kz" -s sub "(objectclass=*)" > > ldap_bind: Authentication method not supported (7) > > additional info: auth method not supported > > > > > > [root@xat noarch]# ldapsearch -x -D "cn=directory manager" -w secret -s base > > dn: > > objectClass: top > > namingContexts: dc=example,dc=kz > > namingContexts: o=netscaperoot > > defaultnamingcontext: dc=example,dc=kz > > supportedExtension: 2.16.840.1.113730.3.5.7 > > supportedExtension: 2.16.840.1.113730.3.5.8 > > supportedExtension: 2.16.840.1.113730.3.5.3 > > supportedExtension: 2.16.840.1.113730.3.5.12 > > supportedExtension: 2.16.840.1.113730.3.5.5 > > supportedExtension: 2.16.840.1.113730.3.5.6 > > supportedExtension: 2.16.840.1.113730.3.5.9 > > supportedExtension: 2.16.840.1.113730.3.5.4 > > supportedExtension: 2.16.840.1.113730.3.6.5 > > supportedExtension: 2.16.840.1.113730.3.6.6 > > supportedExtension: 2.16.840.1.113730.3.6.7 > > supportedExtension: 2.16.840.1.113730.3.6.8 > > supportedExtension: 1.3.6.1.4.1.4203.1.11.1 > > supportedControl: 2.16.840.1.113730.3.4.2 > > supportedControl: 2.16.840.1.113730.3.4.3 > > supportedControl: 2.16.840.1.113730.3.4.4 > > supportedControl: 2.16.840.1.113730.3.4.5 > > supportedControl: 1.2.840.113556.1.4.473 > > supportedControl: 2.16.840.1.113730.3.4.9 > > supportedControl: 2.16.840.1.113730.3.4.16 > > supportedControl: 2.16.840.1.113730.3.4.15 > > supportedControl: 2.16.840.1.113730.3.4.17 > > supportedControl: 2.16.840.1.113730.3.4.19 > > supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1 > > supportedControl: 1.3.6.1.4.1.42.2.27.9.5.2 > > supportedControl: 1.2.840.113556.1.4.319 > > supportedControl: 1.3.6.1.4.1.42.2.27.9.5.8 > > supportedControl: 1.3.6.1.4.1.4203.666.5.16 > > supportedControl: 2.16.840.1.113730.3.4.14 > > supportedControl: 2.16.840.1.113730.3.4.20 > > supportedControl: 1.3.6.1.4.1.1466.29539.12 > > supportedControl: 2.16.840.1.113730.3.4.12 > > supportedControl: 2.16.840.1.113730.3.4.18 > > supportedControl: 2.16.840.1.113730.3.4.13 > > supportedSASLMechanisms: EXTERNAL > > supportedSASLMechanisms: GSSAPI > > supportedSASLMechanisms: CRAM-MD5 > > supportedSASLMechanisms: PLAIN > > supportedSASLMechanisms: DIGEST-MD5 > > supportedSASLMechanisms: LOGIN > > supportedLDAPVersion: 2 > > supportedLDAPVersion: 3 > > vendorName: 389 Project > > vendorVersion: 389-Directory/1.3.0.6 B2013.101.06 > > dataversion: 020130629192303020130629192303 > > netscapemdsuffix: cn=ldap://dc=xat,dc=example,dc=kz:389 > > > > > > > > I understand the this not the problem of credential and passwords. But it the problem of authentication mechanism of LDAP > > But where is core of this problem? > > > > P.S: 389-ds is installed on Fedora 18 for PPC64 > > > > Thank you! > > > > -- > > Ilmir Mulyukov > > > > > > > > This message has been scanned for viruses. > > > > Click here to report this email as spam. > > > > > > Team London - choose from an array of local volunteering opportunities by interest, location or amount of time you have spare. > > > > Visit: http://volunteerteam.london.gov.uk > > > > GREATERLONDONAUTHORITY > > EMAIL NOTICE: > > The information in this email may contain confidential or privileged materials. Please read the full email notice at http://www.london.gov.uk/email-notice -- > > 389 users mailing list > > 389-users(a)lists.fedoraproject.org > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > > > > > > > > -- > > 389 users mailing list > > 389-users(a)lists.fedoraproject.org > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > > > > > > -- > > 389 users mailing list > > 389-users(a)lists.fedoraproject.org > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > -- > > 389 users mailing list > > 389-users(a)lists.fedoraproject.org > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > > > > > > > > -- > > 389 users mailing list > > 389-users(a)lists.fedoraproject.org > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > > > > >

1 0

Authentication method not supported
by ilmir＠atacom.kz 16 Jul '13

16 Jul '13

Hello! During the setup the Kolab on system with 389-ds I have found the following message: Your new DS instance 'xat' was successfully created. Creating the configuration directory server . . . Could not authenticate as user 'uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot' to server 'ldap://xat.example.kz:389/o=NetscapeRoot'. Error: Authentication method not supported I thought that may be this is bug of kolab but new instance have the same problem. [root@xat noarch]# ldapsearch -x -D "uid=kolab-service,ou=Special Users,dc=example,dc=kz" -w secret -b "dc=example,dc=kz" -s sub "(objectclass=*)" ldap_bind: Authentication method not supported (7) additional info: auth method not supported [root@xat noarch]# ldapsearch -x -D "cn=directory manager" -w secret -s base dn: objectClass: top namingContexts: dc=example,dc=kz namingContexts: o=netscaperoot defaultnamingcontext: dc=example,dc=kz supportedExtension: 2.16.840.1.113730.3.5.7 supportedExtension: 2.16.840.1.113730.3.5.8 supportedExtension: 2.16.840.1.113730.3.5.3 supportedExtension: 2.16.840.1.113730.3.5.12 supportedExtension: 2.16.840.1.113730.3.5.5 supportedExtension: 2.16.840.1.113730.3.5.6 supportedExtension: 2.16.840.1.113730.3.5.9 supportedExtension: 2.16.840.1.113730.3.5.4 supportedExtension: 2.16.840.1.113730.3.6.5 supportedExtension: 2.16.840.1.113730.3.6.6 supportedExtension: 2.16.840.1.113730.3.6.7 supportedExtension: 2.16.840.1.113730.3.6.8 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 2.16.840.1.113730.3.4.3 supportedControl: 2.16.840.1.113730.3.4.4 supportedControl: 2.16.840.1.113730.3.4.5 supportedControl: 1.2.840.113556.1.4.473 supportedControl: 2.16.840.1.113730.3.4.9 supportedControl: 2.16.840.1.113730.3.4.16 supportedControl: 2.16.840.1.113730.3.4.15 supportedControl: 2.16.840.1.113730.3.4.17 supportedControl: 2.16.840.1.113730.3.4.19 supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1 supportedControl: 1.3.6.1.4.1.42.2.27.9.5.2 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.3.6.1.4.1.42.2.27.9.5.8 supportedControl: 1.3.6.1.4.1.4203.666.5.16 supportedControl: 2.16.840.1.113730.3.4.14 supportedControl: 2.16.840.1.113730.3.4.20 supportedControl: 1.3.6.1.4.1.1466.29539.12 supportedControl: 2.16.840.1.113730.3.4.12 supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.13 supportedSASLMechanisms: EXTERNAL supportedSASLMechanisms: GSSAPI supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: PLAIN supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: LOGIN supportedLDAPVersion: 2 supportedLDAPVersion: 3 vendorName: 389 Project vendorVersion: 389-Directory/1.3.0.6 B2013.101.06 dataversion: 020130629192303020130629192303 netscapemdsuffix: cn=ldap://dc=xat,dc=example,dc=kz:389 I understand the this not the problem of credential and passwords. But it the problem of authentication mechanism of LDAP But where is core of this problem? P.S: 389-ds is installed on Fedora 18 for PPC64 Thank you! -- Ilmir Mulyukov

5 8

certificates
by husam.shabeeb 15 Jul '13

15 Jul '13

Dear friends, This is Husam I hope that you accept me as a new friend in this list , I'm working on the 389 project I need help setting it , Anyone can help me here ! Many thanks in advanced , Sincerely , Husam

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users July 2013