[389-users] Authentication method not supported

ilmir at atacom.kz ilmir at atacom.kz
Sun Jun 30 06:10:33 UTC 2013


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 at 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.

Thank you for helping!

--
Ilmir Mulyukov




From:   Tim Cambridge <tim.cambridge at london.gov.uk>
To:     "'389-users at lists.fedoraproject.org'" 
<389-users at lists.fedoraproject.org>, 
Date:   30.06.2013 04:59
Subject:        Re: [389-users] Authentication method not supported
Sent by:        389-users-bounces at 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 at atacom.kz [mailto:ilmir at atacom.kz] 
Sent: Saturday, June 29, 2013 08:58 PM
To: 389-users at lists.fedoraproject.org <389-users at 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 at 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 at 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 at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20130630/ad461ead/attachment.html>


More information about the 389-users mailing list