Bug 1044121
| Summary: | RHEL7 ipa server with AD Trust fails first net ads user add | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Scott Poore <spoore> |
| Component: | ipa | Assignee: | IPA Maintainers <ipa-maint> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Namita Soman <nsoman> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.0 | CC: | abokovoy, frenaud, jgalipea, pasik, pvoborni, rcritten, sbose |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-10-16 08:55:23 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: | |||
Scott, the failure is due to timing on KDC's MS-PAC cache. We will be solving MS-PAC cache issue in IPA later, with syncrepl protocol support in 389-ds 1.3.2 (not in RHEL 7.0) once it become available. Alexander, Ok, great. So for now I should be able to just run the command a second time to work around the issue? Would it be possible to mark this one for 7.1 for now then so it's not in the 7.0 queue? Thanks, Scott I think we had a ticket already but no bugzilla since the ticket was more of RFE nature. We can move this one to 7.1 (In reply to Alexander Bokovoy from comment #5) > I think we had a ticket already but no bugzilla since the ticket was more of > RFE nature. > > We can move this one to 7.1 I could not find the ticket. Alexander, do you have the number? If yes, I will link this Bugzilla to it, otherwise file a new one. This one is the ticket: https://fedorahosted.org/freeipa/ticket/1302 FYI, I don't think we've seen this in a while in our testing. I double checked test runs from RHEL7.3 and we didn't see it in any of the runs. This is the result: :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ LOG ] :: RHEL7 ipa server with AD Trust works for first net ads user add, bz1044121 :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ BEGIN ] :: Running 'kdestroy -A' :: [ PASS ] :: Command 'kdestroy -A' (Expected 0, got 0) :: [ BEGIN ] :: Running 'echo Secret123|kinit Administrator' Password for Administrator: :: [ PASS ] :: Command 'echo Secret123|kinit Administrator' (Expected 0, got 0) :: [ BEGIN ] :: Running 'net --debuglevel=10 ads user add bz001044121 Secret123 -k -S ipaqa-w2012r2-1.adtest2.qe > /tmp/tmpout.ipa_trust_func_bug_1044121 2>&1' :: [ PASS ] :: Command 'net --debuglevel=10 ads user add bz001044121 Secret123 -k -S ipaqa-w2012r2-1.adtest2.qe > /tmp/tmpout.ipa_trust_func_bug_1044121 2>&1' (Expected 0,255, got 0) :: [ PASS ] :: File '/tmp/tmpout.ipa_trust_func_bug_1044121' should not contain 'Could not add user' :: [ PASS ] :: File '/tmp/tmpout.ipa_trust_func_bug_1044121' should not contain 'Message too long' :: [ PASS ] :: BZ 1044121 not found :: [ BEGIN ] :: Running 'net ads user delete bz001044121 -k -S ipaqa-w2012r2-1.adtest2.qe' User bz001044121 deleted :: [ PASS ] :: Command 'net ads user delete bz001044121 -k -S ipaqa-w2012r2-1.adtest2.qe' (Expected 0, got 0) :: [ BEGIN ] :: Running 'kdestroy -A' :: [ PASS ] :: Command 'kdestroy -A' (Expected 0, got 0) :: [ BEGIN ] :: Running 'echo Secret123|kinit admin' Password for admin: :: [ PASS ] :: Command 'echo Secret123|kinit admin' (Expected 0, got 0) This issue is unlikely to happen any more since this commit: https://pagure.io/freeipa/c/73f61ce214e784ab8176a1f7acac6a3dbf1474ae ipa-kdb: update trust information in all workers (done on master branch, also present in 4.7.0). A backport has been done in ipa-4-6 branch with https://pagure.io/freeipa/c/5973f09696ea3f1bed37b33a2b7caf317da63f1b ipa-kdb: update trust information in all workers (available on FreeIPA 4.6.4, which was the base for rhel 7.6). Hence closing as CURRENTRELEASE. |
Description of problem: In an IPA environment with a cross domain trust to AD env, I'm seeing this fail on the first attempt: :: [ FAIL ] :: Running 'net --debuglevel=10 ads user add au112131936 Secret123 -k -S win-i94qhqmthd4.adlabs.com > /tmp/tmpout.ad_user_add 2>&1' (Expected 0, got 255) It looks like all similar "net ads user add" commands for different users work after the first failed. Version-Release number of selected component (if applicable): samba-common-4.1.0-3.el7.x86_64 How reproducible: Always in automated tests in my env. However, I have not seen this when it is run manually. Steps to Reproduce: 0. Make sure server is setup for hostname that IPA and AD will expect (/etc/hosts and /etc/hostname may need to be set) 1. yum -y install ipa-server bind-dyndb-ldap 2. ipa-server-install --setup-dns --forwarder=$DNSFORWARD \ --hostname=$hostname_s.$DOMAIN -r $RELM -n $DOMAIN \ -p $ADMINPW -P $ADMINPW -a $ADMINPW -U 3. yum -y install samba-client samba-winbind-clients ipa-server-trust-ad 4. ipa-adtrust-install --netbios-name=$NBNAME -a $ADMINPW -U 5. ipa dnszone-add $AD_top_domain --name-server=$AD_top_host. \ --admin-email=\"hostmaster@$AD_top_domain\" --force \ --forwarder=$AD_top_ip --forward-policy=only \ --ip-address=$AD_top_ip 6. service named reload 7. Log into Windows and add DNS Conditional Forwarder for IPA domain 8. echo $ADMINPW | ipa trust-add $AD_top_domain --admin $AD_top_admin \ --range-type=ipa-ad-trust --password 9. net ads user add <username> -k -S $AD_top_host Actual results: :: [ FAIL ] :: Running 'net --debuglevel=10 ads user add au112131936 Secret123 -k -S win-i94qhqmthd4.adlabs.com > /tmp/tmpout.ad_user_add 2>&1' (Expected 0, got 255) Looking at the end of the debug output: recv of chpw reply failed (Message too long) Could not add user au112131936. Error setting password Message too long return code = -1 And uesr not added to AD. Expected results: User added without error. Additional info: