Bug 1004823

Summary: join fails with adlci on ppc64
Product: Red Hat Enterprise Linux 7 Reporter: Patrik Kis <pkis>
Component: adcliAssignee: Stef Walter <stefw>
Status: CLOSED CURRENTRELEASE QA Contact: Patrik Kis <pkis>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.0CC: dspurek, pkis
Target Milestone: rcKeywords: TestBlocker
Target Release: ---   
Hardware: ppc64   
OS: Unspecified   
Whiteboard:
Fixed In Version: adcli-0.7.4-1.el7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-06-13 11:55:25 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

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.