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 1004442 - join with adlci fails on CLDAP ping when the first discovered address is IPv6
Summary: join with adlci fails on CLDAP ping when the first discovered address is IPv6
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: adcli
Version: 7.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Stef Walter
QA Contact: Patrik Kis
URL:
Whiteboard:
Depends On: 1007421
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-09-04 16:04 UTC by Patrik Kis
Modified: 2014-06-13 12:28 UTC (History)
4 users (show)

Fixed In Version: adcli-0.7.5-1.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-13 12:28:20 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Don't use cldap with IPv6 due to openldap bugs (1.00 KB, patch)
2013-09-12 16:14 UTC, Stef Walter 		no flags Details | Diff
View All


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

Description Patrik Kis 2013-09-04 16:04:00 UTC 
Description of problem:
This is most probably a regression from bug 996995.
With releases realmd-0.14.4-1.el7 and older the problem was not observed because there cldap ping is done against hostname and not ip address.

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

How reproducible:
90%

Steps to Reproduce:
1. Have a client and AD booth with IPv4 and also IPv6 addresses
2. Join with adlci
# echo Pass2012! | realm -v join --user=Amy-admin --client-software=sssd --membership-software=adcli ad.baseos.qe
 * Resolving: _ldap._tcp.ad.baseos.qe
 * Performing LDAP DSE lookup on: 2620:52:0:2223::1:1
 * Performing LDAP DSE lookup on: 2620:52:0:2223:1dfe:a8ea:f0d8:380c
 * Performing LDAP DSE lookup on: 10.34.37.22
 * Successfully discovered: ad.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 ad.baseos.qe --domain-realm AD.BASEOS.QE --domain-controller 2620:52:0:2223::1:1 --login-type user --login-user Amy-admin --stdin-password
 * Using domain name: ad.baseos.qe
 * Calculated computer account name from fqdn: PES-GUEST-106
 * Using domain realm: ad.baseos.qe
 ! Couldn't perform discovery on server: cldap://2620:52:0:2223::1:1: Bad parameter to an ldap routine
 ! Couldn't initialize LDAP connection: Bad parameter to an ldap routine:
adcli: couldn't connect to ad.baseos.qe domain: Couldn't initialize LDAP connection: Bad parameter to an ldap routine:
 ! Failed to join the domain
realm: Couldn't join realm: Failed to join the domain

NOTE: in this case no CLAP ping was sent out from the test machine (monitored by wireshark) so most probably the routine is not correctly called (cldap://2620:52:0:2223::1:1: << is this colon ok here? looks strange)

3. BUT, when the 1st address in initial discovery IPv4 (it happen once from 20 cases) the join passes
# echo Pass2012! | realm -v join --user=Amy-admin --client-software=sssd --membership-software=adcli ad.baseos.qe
 * Resolving: _ldap._tcp.ad.baseos.qe
 * Performing LDAP DSE lookup on: 10.34.37.22
 * Performing LDAP DSE lookup on: 2620:52:0:2223:1dfe:a8ea:f0d8:380c
 * Performing LDAP DSE lookup on: 2620:52:0:2223::1:1
 * Successfully discovered: ad.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 ad.baseos.qe --domain-realm AD.BASEOS.QE --domain-controller 10.34.37.22 --login-type user --login-user Amy-admin --stdin-password
 * Using domain name: ad.baseos.qe
 * Calculated computer account name from fqdn: PES-GUEST-106
 * 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 /var/cache/realmd/adcli-krb5-OHTaJR/krb5.d/adcli-krb5-conf-KBC4Hm
 * Authenticated as user: Amy-admin.QE
 * Looked up short domain name: AD
 * Using fully qualified name: pes-guest-106.ad.baseos.qe
 * Using domain name: ad.baseos.qe
 * Using computer account name: PES-GUEST-106
 * Using domain realm: ad.baseos.qe
 * Enrolling computer account name calculated from fqdn: PES-GUEST-106
 * Generated 120 character computer password
 * Using keytab: FILE:/etc/krb5.keytab
 * Using fully qualified name: pes-guest-106.ad.baseos.qe
 * Using domain name: ad.baseos.qe
 * Using computer account name: PES-GUEST-106
 * Using domain realm: ad.baseos.qe
 * Looked up short domain name: AD
 * Found computer account for PES-GUEST-106$ at: CN=pes-guest-106,CN=Computers,DC=ad,DC=baseos,DC=qe
 * Set computer password
 * Retrieved kvno '8' for computer account in directory: CN=pes-guest-106,CN=Computers,DC=ad,DC=baseos,DC=qe
 * Modifying computer account: userAccountControl
 * Modifying computer account: operatingSystemVersion, operatingSystemServicePack
 * Modifying computer account: userPrincipalName
 * Discovered which keytab salt to use
 * Added the entries to the keytab: PES-GUEST-106$@AD.BASEOS.QE: FILE:/etc/krb5.keytab
 * Added the entries to the keytab: HOST/PES-GUEST-106.QE: FILE:/etc/krb5.keytab
 * Added the entries to the keytab: HOST/pes-guest-106.ad.baseos.qe.QE: FILE:/etc/krb5.keytab
 * Added the entries to the keytab: RestrictedKrbHost/PES-GUEST-106.QE: FILE:/etc/krb5.keytab
 * Added the entries to the keytab: RestrictedKrbHost/pes-guest-106.ad.baseos.qe.QE: FILE:/etc/krb5.keytab
 * /usr/bin/systemctl enable sssd.service
...
Comment 2 Stef Walter 2013-09-06 13:31:51 UTC 
Patches available upstream. Part of reworking adcli to use all addresses during discovery.
Comment 3 Patrik Kis 2013-09-10 14:48:49 UTC 
Hi Stef,

it seems that the cldap ping was fixed but there is still issue with IPv6. I'm not 100% sure that is is caused by adlci itself but so far it looks like.

# rpm -q adcli
adcli-0.7.4-1.el7.x86_64
# ping6 2620:52:0:2223::1:1
PING 2620:52:0:2223::1:1(2620:52:0:2223::1:1) 56 data bytes
64 bytes from 2620:52:0:2223::1:1: icmp_seq=1 ttl=58 time=167 ms
64 bytes from 2620:52:0:2223::1:1: icmp_seq=2 ttl=58 time=164 ms
64 bytes from 2620:52:0:2223::1:1: icmp_seq=3 ttl=58 time=162 ms
^C
--- 2620:52:0:2223::1:1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 162.582/164.939/167.591/2.108 ms
#
#
# adcli delete-computer -v --domain ad.baseos.qe --domain-realm AD.BASEOS.QE --domain-controller 2620:52:0:2223::1:1 --login-user amy-admin ad.baseos.qe * Using domain name: ad.baseos.qe
 * Calculated computer account name from fqdn: RAALMDTEST
 * Using domain realm: ad.baseos.qe
 * Sending cldap pings to domain controller: 2620:52:0:2223::1:1
 ! Couldn't perform discovery search: Can't contact LDAP server
 ! Couldn't perform discovery search: Can't contact LDAP server
 ! Couldn't perform discovery search: Can't contact LDAP server
 ! Couldn't perform discovery search: Can't contact LDAP server
 ! Couldn't perform discovery search: Can't contact LDAP server
 ! Couldn't perform discovery search: Can't contact LDAP server
 ! Couldn't perform discovery search: Can't contact LDAP server
 ! Couldn't perform discovery search: Can't contact LDAP server
 ! Couldn't perform discovery search: Can't contact LDAP server
 ! Couldn't perform discovery search: Can't contact LDAP server
 ! Couldn't perform discovery search: Can't contact LDAP server
 ! Couldn't perform discovery search: Can't contact LDAP server
 ! Couldn't perform discovery search: Can't contact LDAP server
 ! Couldn't perform discovery search: Can't contact LDAP server
 ! Couldn't perform discovery search: Can't contact LDAP server
 ! Couldn't perform discovery search: Can't contact LDAP server
 ! Couldn't perform discovery search: Can't contact LDAP server
 ! Couldn't perform discovery search: Can't contact LDAP server
 ! Couldn't perform discovery search: Can't contact LDAP server
 ! Couldn't perform discovery search: Can't contact LDAP server
 ! Couldn't perform discovery search: Can't contact LDAP server
 ! Couldn't perform discovery search: Can't contact LDAP server
 ! Couldn't perform discovery search: Can't contact LDAP server
 ! Couldn't perform discovery search: Can't contact LDAP server
 ! Couldn't initialize LDAP connection: Bad parameter to an ldap routine:
adcli: couldn't connect to ad.baseos.qe domain: Couldn't initialize LDAP connection: Bad parameter to an ldap routine:


and this looks suspicious (see the IPv6 address below, it seems to be truncated "2620:52:0:2223::"):

# strace adcli delete-computer -v --domain ad.baseos.qe --domain-realm AD.BASEOS.QE --domain-controller 2620:52:0:2223::1:1 --login-user amy-admin ad.baseos.qe 

/SNIP

getsockname(3, {sa_family=AF_NETLINK, pid=2979, groups=00000000}, [12]) = 0
sendto(3, "\24\0\0\0\26\0\1\3\3060/R\0\0\0\0\0\0\0\0", 20, 0, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 20
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"D\0\0\0\24\0\2\0\3060/R\243\v\0\0\2\10\200\376\1\0\0\0\10\0\1\0\177\0\0\1"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 140
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"@\0\0\0\24\0\2\0\3060/R\243\v\0\0\n\200\200\376\1\0\0\0\24\0\1\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 192
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\24\0\0\0\3\0\2\0\3060/R\243\v\0\0\0\0\0\0", 4096}], msg_controllen=0, msg_flags=0}, 0) = 20
close(3)                                = 0
socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 3
fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
sendto(3, "0@\2\1\1c;\4\0\n\1\0\n\1\0\2\1\0\2\1\0\1\1\0\240\34\243\r\4\5Nt"..., 66, 0, {sa_family=AF_INET6, sin6_port=htons(389), inet_pton(AF_INET6, "2620:52:0:2223::", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 16) = -1 EINVAL (Invalid argument)
write(2, " ! Couldn't perform discovery se"..., 64 ! Couldn't perform discovery search: Can't contact LDAP server
) = 64
Comment 4 Stef Walter 2013-09-12 16:14:58 UTC 
Created attachment 796925 [details]
Don't use cldap with IPv6 due to openldap bugs
Comment 5 Stef Walter 2013-09-13 08:11:16 UTC 
Documentations heads up:

Added workaround to adcli to not use CLDAP with IPv6, and use LDAP instead. This has the work around that Windows 2003 domains are not joinable using IPv6, as they do not support discovery using LDAP (only CLDAP).
Comment 6 Stef Walter 2013-09-13 08:20:31 UTC 
New adcli 0.7.5 build should fix this. Tested like so:

[root@ppc64-m00 ~]# adcli delete-computer -v --domain ad.baseos.qe --domain-realm AD.BASEOS.QE --domain-controller 2620:52:0:2223::1:1 --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 netlogon pings to domain controller: ldap://[2620:52:0:2223::1:1]
 * Received NetLogon info from: sec-ad1.ad.baseos.qe
 * Wrote out krb5.conf snippet to /tmp/adcli-krb5-Bc8fTd/krb5.d/adcli-krb5-conf-GLHK7m
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 9 Ludek Smid 2014-06-13 12:28:20 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.