On 06/30/2013 12:10 AM, ilmir@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@london.gov.uk>
To:        "'389-users@lists.fedoraproject.org'" <389-users@lists.fedoraproject.org>,
Date:        30.06.2013 04:59
Subject:        Re: [389-users] Authentication method not supported
Sent by:        389-users-bounces@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@atacom.kz [mailto:ilmir@atacom.kz]
Sent
: Saturday, June 29, 2013 08:58 PM
To
: 389-users@lists.fedoraproject.org <389-users@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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users



--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users