Bug 1004823 - join fails with adlci on ppc64
Summary: join fails with adlci on ppc64
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: adcli
Version: 7.0
Hardware: ppc64
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Stef Walter
QA Contact: Patrik Kis
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-09-05 14:41 UTC by Patrik Kis
Modified: 2014-06-13 11:55 UTC (History)
2 users (show)

Fixed In Version: adcli-0.7.4-1.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-13 11:55:25 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
FreeDesktop.org 69038 0 None None None Never

Description Patrik Kis 2013-09-05 14:41:20 UTC
Description of problem:
It is not possible to join to AD domain on s390x and ppc64 with adcli as membersip-software.

Version-Release number of selected component (if applicable):
realmd-0.14.5-1.el7

How reproducible:
100%

Steps to Reproduce:
# echo Pass2012! | realm -v join -U amy-admin --membership-software=adcli security.baseos.qe
 * Resolving: _ldap._tcp.security.baseos.qe
 * Performing LDAP DSE lookup on: 10.34.36.170
 * Successfully discovered: security.baseos.qe
Password for amy-admin: 
 * Required files: /usr/sbin/oddjobd, /usr/libexec/oddjob/mkhomedir, /usr/sbin/sssd, /usr/sbin/adcli
 * LANG=C /usr/sbin/adcli join --verbose --domain security.baseos.qe --domain-realm SECURITY.BASEOS.QE --domain-controller 10.34.36.170 --login-type user --login-user amy-admin --stdin-password
 * Using domain name: security.baseos.qe
 * Calculated computer account name from fqdn: IBM-Z10-30
 * Using domain realm: security.baseos.qe
 * Sending cldap pings to domain controller: 10.34.36.170
 * Received NetLogon info from: DC.security.baseos.qe
 * Wrote out krb5.conf snippet to /var/cache/realmd/adcli-krb5-nmkLoP/krb5.d/adcli-krb5-conf-Po36hh
 * Authenticated as user: amy-admin.QE
 ! Couldn't authenticate to active directory: SASL(-4): no mechanism available: No worthy mechs found
adcli: couldn't connect to security.baseos.qe domain: Couldn't authenticate to active directory: SASL(-4): no mechanism available: No worthy mechs found
 ! Insufficient permissions to join the domain
realm: Couldn't join realm: Insufficient permissions to join the domain


NOTE: if the join does not run into this error then it run into the one reported in bug 1004442. It depends if the command:
 * LANG=C /usr/sbin/adcli join --verbose --domain security.baseos.qe --domain-realm SECURITY.BASEOS.QE --domain-controller 
has IPv4 or IPv6. With IPv4 it is this error and with IPv6 the error from bug 1004442.

Comment 1 Patrik Kis 2013-09-06 09:49:58 UTC
It seems that the issue is caused by adcli directly:

# adcli -v delete-computer --domain=ad.baseos.qe --domain-controller=10.34.37.22 ibm-p750e-02-lp.ad.baseos.qe
 * Using domain name: ad.baseos.qe
 * Calculated computer account name from fqdn: IBM-P750E-02-LP
 * Calculated domain realm from name: AD.BASEOS.QE
 * Sending cldap pings to domain controller: 10.34.37.22
 * Received NetLogon info from: sec-ad1.ad.baseos.qe
 * Wrote out krb5.conf snippet to /tmp/adcli-krb5-97OXE6/krb5.d/adcli-krb5-conf-5ycpN2
Password for Administrator.QE: 
 * Authenticated as user: Administrator.QE
 ! Couldn't authenticate to active directory: SASL(-4): no mechanism available: No worthy mechs found
adcli: couldn't connect to ad.baseos.qe domain: Couldn't authenticate to active directory: SASL(-4): no mechanism available: No worthy mechs found

Comment 4 Stef Walter 2013-09-06 09:53:58 UTC
Please try the following commands:

$ kinit Administrator.QE
$ ldapwhoami -H ldap://sec-ad1.ad.baseos.qe -Y GSSAPI

These should complete successfully and output your login name.

Comment 5 Patrik Kis 2013-09-06 13:45:51 UTC
(In reply to Stef Walter from comment #4)
> Please try the following commands:
> 
> $ kinit Administrator.QE
> $ ldapwhoami -H ldap://sec-ad1.ad.baseos.qe -Y GSSAPI
> 
> These should complete successfully and output your login name.

I get different output on ppc64 and s390x, but I'd say because it used different addresses:

PPC64:

# kinit Administrator.QE
Password for Administrator.QE: 
#  ldapwhoami -H ldap://sec-ad1.ad.baseos.qe -Y GSSAPI
SASL/GSSAPI authentication started
SASL username: Administrator.QE
SASL SSF: 56
SASL data security layer installed.
u:AD\Administrator
# 
# adcli -v delete-computer --domain=ad.baseos.qe --domain-controller=10.34.37.22 `hostname`
 * Using domain name: ad.baseos.qe
 * Calculated computer account name from fqdn: IBM-P720-01-LP4
 * Calculated domain realm from name: AD.BASEOS.QE
 * Sending cldap pings to domain controller: 10.34.37.22
 * Received NetLogon info from: sec-ad1.ad.baseos.qe
 * Wrote out krb5.conf snippet to /tmp/adcli-krb5-Dq4vXj/krb5.d/adcli-krb5-conf-UKAUnb
Password for Administrator.QE: 
 * Authenticated as user: Administrator.QE
 ! Couldn't authenticate to active directory: SASL(-4): no mechanism available: No worthy mechs found
adcli: couldn't connect to ad.baseos.qe domain: Couldn't authenticate to active directory: SASL(-4): no mechanism available: No worthy mechs found


S390x:

# kinit Administrator.QE
Password for Administrator.QE: 
#  ldapwhoami -H ldap://sec-ad1.ad.baseos.qe -Y GSSAPI
ldap_sasl_interactive_bind_s: Unknown authentication method (-6)
	additional info: SASL(-4): no mechanism available: No worthy mechs found
# adcli -v delete-computer --domain=ad.baseos.qe --domain-controller=10.34.37.22 `hostname`
 * Using domain name: ad.baseos.qe
 * Calculated computer account name from fqdn: IBM-Z10-30
 * Calculated domain realm from name: AD.BASEOS.QE
 * Sending cldap pings to domain controller: 10.34.37.22
 * Received NetLogon info from: sec-ad1.ad.baseos.qe
 * Wrote out krb5.conf snippet to /tmp/adcli-krb5-t44PFw/krb5.d/adcli-krb5-conf-rjAyZI
Password for Administrator.QE: 
 * Authenticated as user: Administrator.QE
 ! Couldn't authenticate to active directory: SASL(-4): no mechanism available: No worthy mechs found
adcli: couldn't connect to ad.baseos.qe domain: Couldn't authenticate to active directory: SASL(-4): no mechanism available: No worthy mechs found

Comment 6 Stef Walter 2013-09-06 14:13:07 UTC
(In reply to Patrik Kis from comment #5)
> S390x:
> 
> # kinit Administrator.QE
> Password for Administrator.QE: 
> #  ldapwhoami -H ldap://sec-ad1.ad.baseos.qe -Y GSSAPI
> ldap_sasl_interactive_bind_s: Unknown authentication method (-6)
> 	additional info: SASL(-4): no mechanism available: No worthy mechs found

So on s390x this seems broken in openldap or krb5 gssapi. Ignoring s390x for this bug report. You may wish to file a separate bug report to follow up on this with those maintainers.

On ppc64 this does seem like an adcli problem. Persuing...

Comment 7 Patrik Kis 2013-09-06 14:36:06 UTC
The s390x case was filed in bug 1005267 (openldap)

Comment 8 Stef Walter 2013-09-06 14:48:26 UTC
Patch upstream for adcli.

Comment 9 Patrik Kis 2013-09-10 14:53:22 UTC
This fix looks ok at the first glance:

# rpm -q adcli
adcli-0.7.2-1.el7.ppc64
# adcli delete-computer -v --domain ad.baseos.qe --domain-realm AD.BASEOS.QE --domain-controller 10.34.37.22 --login-user amy-admin ad.baseos.qe
 * Using domain name: ad.baseos.qe
 * Calculated computer account name from fqdn: PPC64-M00
 * Using domain realm: ad.baseos.qe
 * Sending cldap pings to domain controller: 10.34.37.22
 * Received NetLogon info from: sec-ad1.ad.baseos.qe
 * Wrote out krb5.conf snippet to /tmp/adcli-krb5-Gvo8f3/krb5.d/adcli-krb5-conf-93orYY
Password for amy-admin.QE: 
 * Authenticated as user: amy-admin.QE
 ! Couldn't authenticate to active directory: SASL(-4): no mechanism available: No worthy mechs found
adcli: couldn't connect to ad.baseos.qe domain: Couldn't authenticate to active directory: SASL(-4): no mechanism available: No worthy mechs found
#
#
#
#
# rpm -Uvh adcli-0.7.4-1.el7.ppc64.rpm 
Preparing...                          ################################# [100%]
Updating / installing...
   1:adcli-0.7.4-1.el7                ################################# [ 50%]
Cleaning up / removing...
   2:adcli-0.7.2-1.el7                ################################# [100%]
# adcli delete-computer -v --domain ad.baseos.qe --domain-realm AD.BASEOS.QE --domain-controller 10.34.37.22 --login-user amy-admin ad.baseos.qe
 * Using domain name: ad.baseos.qe
 * Calculated computer account name from fqdn: PPC64-M00
 * Using domain realm: ad.baseos.qe
 * Sending cldap pings to domain controller: 10.34.37.22
 * Received NetLogon info from: sec-ad1.ad.baseos.qe
 * Wrote out krb5.conf snippet to /tmp/adcli-krb5-eV0pj1/krb5.d/adcli-krb5-conf-SZUWoX
Password for amy-admin.QE: 
 * Authenticated as user: amy-admin.QE
 * Looked up short domain name: AD
 * Using fully qualified name: ppc64-m00.lab.eng.brq.redhat.com
 * Using domain name: ad.baseos.qe
 * Using computer account name: PPC64-M00
 * Using domain realm: ad.baseos.qe
 * Using fully qualified name: ad.baseos.qe
 * Calculated computer account name from fqdn: AD
 * Computer account for AD$ does not exist
 ! No computer account for AD$ exists
adcli: deleting ad.baseos.qe in ad.baseos.qe domain failed: No computer account for AD$ exists
#

Comment 12 Ludek Smid 2014-06-13 11:55:25 UTC
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.


Note You need to log in before you can comment on or make changes to this bug.