Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1004823

Summary:	join fails with adlci on ppc64
Product:	Red Hat Enterprise Linux 7	Reporter:	Patrik Kis <pkis>
Component:	adcli	Assignee:	Stef Walter <stefw>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Patrik Kis <pkis>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.0	CC:	dspurek, pkis
Target Milestone:	rc	Keywords:	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:
Embargoed:

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.