Bug 1004823 - join fails with adlci on ppc64
join fails with adlci on ppc64
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: adcli (Show other bugs)
7.0
ppc64 Unspecified
medium Severity medium
: rc
: ---
Assigned To: Stef Walter
Patrik Kis
: TestBlocker
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-05 10:41 EDT by Patrik Kis
Modified: 2014-06-13 07:55 EDT (History)
2 users (show)

See Also:
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 07:55:25 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
FreeDesktop.org 69038 None None None Never

  None (edit)
Description Patrik Kis 2013-09-05 10:41:20 EDT
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@SECURITY.BASEOS.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 05:49:58 EDT
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@AD.BASEOS.QE: 
 * Authenticated as user: Administrator@AD.BASEOS.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 05:53:58 EDT
Please try the following commands:

$ kinit Administrator@AD.BASEOS.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 09:45:51 EDT
(In reply to Stef Walter from comment #4)
> Please try the following commands:
> 
> $ kinit Administrator@AD.BASEOS.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@AD.BASEOS.QE
Password for Administrator@AD.BASEOS.QE: 
#  ldapwhoami -H ldap://sec-ad1.ad.baseos.qe -Y GSSAPI
SASL/GSSAPI authentication started
SASL username: Administrator@AD.BASEOS.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@AD.BASEOS.QE: 
 * Authenticated as user: Administrator@AD.BASEOS.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@AD.BASEOS.QE
Password for Administrator@AD.BASEOS.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@AD.BASEOS.QE: 
 * Authenticated as user: Administrator@AD.BASEOS.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 10:13:07 EDT
(In reply to Patrik Kis from comment #5)
> S390x:
> 
> # kinit Administrator@AD.BASEOS.QE
> Password for Administrator@AD.BASEOS.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 10:36:06 EDT
The s390x case was filed in bug 1005267 (openldap)
Comment 8 Stef Walter 2013-09-06 10:48:26 EDT
Patch upstream for adcli.
Comment 9 Patrik Kis 2013-09-10 10:53:22 EDT
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@AD.BASEOS.QE: 
 * Authenticated as user: amy-admin@AD.BASEOS.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@AD.BASEOS.QE: 
 * Authenticated as user: amy-admin@AD.BASEOS.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 07:55:25 EDT
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.