Authentication method not supported

List overview All Threads
Download

newer

older

Re: [389-users] Authentication...

certificates

ilmir＠atacom.kz

29 Jun 2013 29 Jun '13

2:58 p.m.

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

Attachments:

attachment.html (text/html — 6.3 KB)

Show replies by date

Tim Cambridge

29 Jun 29 Jun

5:59 p.m.

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:

I thought that may be this is bug of kolab but new instance have the same problem.

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 herehttps://www.mailcontrol.com/sr/OQG740jg9hrGX2PQPOmvUnWT5wH6X0A!hZ5YvCfT9UuZx8KlL0fvIc8XMIbqrTb!Q0XxGjfGlPhsVqdfswMBgw== 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

GREATER LONDON AUTHORITY ------------------------------------------------------------------------------------ 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 ------------------------------------------------------------------------------------

ilmir＠atacom.kz

30 Jun 30 Jun

1:10 a.m.

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.

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

Hello! During the setup the Kolab on system with 389-ds I have found the following message:

I thought that may be this is bug of kolab but new instance have the same problem.

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

Rich Megginson

1 Jul 1 Jul

9:06 a.m.

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_ https://www.mailcontrol.com/sr/OQG740jg9hrGX2PQPOmvUnWT5wH6X0A%21hZ5YvCfT9UuZx8KlL0fvIc8XMIbqrTb%21Q0XxGjfGlPhsVqdfswMBgw==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_ http://volunteerteam.london.gov.uk/

GREATER*LONDON*AUTHORITY *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

Ludwig Krispenz

9:42 a.m.

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@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_ https://www.mailcontrol.com/sr/OQG740jg9hrGX2PQPOmvUnWT5wH6X0A%21hZ5YvCfT9UuZx8KlL0fvIc8XMIbqrTb%21Q0XxGjfGlPhsVqdfswMBgw==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_ http://volunteerteam.london.gov.uk/

GREATER*LONDON*AUTHORITY *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

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

ilmir＠atacom.kz

14 Jul 14 Jul

9:38 p.m.

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@redhat.com To: "General discussion list for the 389 Directory server project." 389-users@lists.fedoraproject.org, Date: 01.07.2013 20:42 Subject: Re: [389-users] Authentication method not supported Sent by: 389-users-bounces@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@atacom.kz wrote: Good morning! Yes. Accesslog level is 772:

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

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

Hello! During the setup the Kolab on system with 389-ds I have found the following message:

I thought that may be this is bug of kolab but new instance have the same problem.

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

-- 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 -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users

Paul Robert Marino

15 Jul 15 Jul

midnight

Rich Megginson

9:59 a.m.

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.

...

-- Sent from my HP Pre3

On Jul 14, 2013 10:38 PM, ilmir@atacom.kz ilmir@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 http://www.atacom.kz/

From: Ludwig Krispenz lkrispen@redhat.com To: "General discussion list for the 389 Directory server project." 389-users@lists.fedoraproject.org, Date: 01.07.2013 20:42 Subject: Re: [389-users] Authentication method not supported Sent by: 389-users-bounces@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@atacom.kz_ mailto:ilmir@atacom.kzwrote: 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_ mailto:tim.cambridge@london.gov.uk To: _"'389-users@lists.fedoraproject.org'"_ mailto:%27389-users@lists.fedoraproject.org%27_389-users@lists.fedoraproject.org_ mailto: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_

mailto: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[_mailto:ilmir@atacom.kz_] * Sent*: Saturday, June 29, 2013 08:58 PM* To*: _389-users@lists.fedoraproject.org_ mailto:389-users@lists.fedoraproject.org_389-users@lists.fedoraproject.org_ mailto: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_/ 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_ https://www.mailcontrol.com/sr/OQG740jg9hrGX2PQPOmvUnWT5wH6X0A%21hZ5YvCfT9UuZx8KlL0fvIc8XMIbqrTb%21Q0XxGjfGlPhsVqdfswMBgw==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_ http://volunteerteam.london.gov.uk/

GREATER*LONDON*AUTHORITY* 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_ mailto:389-users@lists.fedoraproject.org_ __https://admin.fedoraproject.org/mailman/listinfo/389-users_

-- 389 users mailing list _389-users@lists.fedoraproject.org_ mailto:389-users@lists.fedoraproject.org _https://admin.fedoraproject.org/mailman/listinfo/389-users_

-- 389 users mailing list _389-users@lists.fedoraproject.org_ mailto: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

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

ilmir＠atacom.kz

16 Jul 16 Jul

12:24 a.m.

Good morning! I can build or test on IBM Power 7 platform.

From: Rich Megginson rmeggins@redhat.com To: "General discussion list for the 389 Directory server project." 389-users@lists.fedoraproject.org, Cc: 389-users-bounces@lists.fedoraproject.org Date: 15.07.2013 20:59 Subject: Re: [389-users] Authentication method not supported Sent by: 389-users-bounces@lists.fedoraproject.org

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.

-- Sent from my HP Pre3

On Jul 14, 2013 10:38 PM, ilmir@atacom.kz ilmir@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.

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@atacom.kz wrote: Good morning! Yes. Accesslog level is 772:

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

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

Hello! During the setup the Kolab on system with 389-ds I have found the following message:

I thought that may be this is bug of kolab but new instance have the same problem.

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

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

3947

Age (days ago)

3964

Last active (days ago)

389-users@lists.fedoraproject.org

8 comments

5 participants

tags (0)

participants (5)

ilmir＠atacom.kz
Ludwig Krispenz
Paul Robert Marino
Rich Megginson
Tim Cambridge