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 988473

Summary: CIFS denied credentials when establishing trust
Product: Red Hat Enterprise Linux 8 Reporter: James Findley <james.findley>
Component: ipaAssignee: IPA Maintainers <ipa-maint>
Status: CLOSED UPSTREAM QA Contact: ipa-qe <ipa-qe>
Severity: unspecified Docs Contact: Vendula Ferschmannova <vferschm>
Priority: medium    
Version: 8.0CC: abokovoy, dpal, jgalipea, lmanasko, pasik, pvoborni, rcritten, sbose, sprabhu, ssorce, swhiteho, tscherf
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Known Issue
Doc Text:
Access control to lightweight directory access protocol (LDAP) objects representing trust with Active Directory (AD) is given to the "Trusted Admins" group in Identity Management. In order to establish the trust, the Identity Management administrator should belong to a group which is a member of the "Trusted Admins" group and this group should have relative identifier (RID) 512 assigned. To ensure this, run the "ipa-adtrust-install" command and then the "ipa group-show admins --all" command to verify that the "ipantsecurityidentifier" field contains a value ending with the "-512" string. If the field does not end with "-512", use the "ipa group-mod admins --setattr=ipantsecurityidentifier=SID" command, where SID is the value of the field from the "ipa group-show admins --all" command output with the last component value (-XXXX) replaced by the "-512" string.
 Story Points: ---
Clone Of: Environment:
Last Closed: 2019-07-04 13:25:31 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:
Attachments:
Description Flags
smbd logs
none
httpd logs none

Description James Findley 2013-07-25 16:22:16 UTC 
Created attachment 778387 [details]
smbd logs

Description of problem:

When establishing a trust with:

ipa trust-add --all --type=ad addomain.com --admin='my.name' --password --base-id=791200000 --range-size=200000
 
The trust setup fails, printing the following error:
ipa: DEBUG: Caught fault 2100 from server https://ipa.ipadomain.com/ipa/xml: Insufficient access: CIFS server denied your credentials
ipa: DEBUG: Destroyed connection context.xmlclient
ipa: ERROR: Insufficient access: CIFS server denied your credentials

Version-Release number of selected component (if applicable):
ipa-server-3.0.0-26.el6_4.2.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Create user in a group that has all privileges selected
2. Use this user to create a trust
3.

Actual results:

Above error

Expected results:

Trust created

Additional info:

I've attached samba logs at level 11 and the apache logs.
Comment 1 James Findley 2013-07-25 16:23:12 UTC 
Created attachment 778389 [details]
httpd logs
Comment 3 Martin Kosek 2013-07-26 07:11:24 UTC 
This seems to be the relevant errors from httpd error log:

tevent: Schedule immediate event "dcerpc_io_trigger": 0x7ff9d426bd50
tevent: Added timed event "dcerpc_timeout_handler": 0x7ff9d4293740
tevent: Run immediate event "dcerpc_io_trigger": 0x7ff9d426bd50
tevent: Schedule immediate event "dcerpc_io_trigger": 0x7ff9d426bd50
num_setup=2, max_setup=0, param_total=0, this_param=0, max_param=0, data_total=1272, this_data=1272, max_data=4280, param_offset=84, param_pad=2, param_disp=0, data_offset=84, data_pad=0, data_disp=0
tevent: Added timed event "tevent_req_timedout": 0x7ff9d4341e40
tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7ff9d4139d30
tevent: Run immediate event "dcerpc_io_trigger": 0x7ff9d426bd50
tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7ff9d4139d30
tevent: Schedule immediate event "tevent_req_trigger": 0x7ff9d4144070
tevent: Run immediate event "tevent_req_trigger": 0x7ff9d4144070
tevent: Destroying timer event 0x7ff9d4341e40 "tevent_req_timedout"
tevent: Destroying timer event 0x7ff9d4293740 "dcerpc_timeout_handler"
tevent: Schedule immediate event "tevent_req_trigger": 0x7ff9d42acb80
tevent: Run immediate event "tevent_req_trigger": 0x7ff9d42acb80
     lsa_CreateTrustedDomainEx2: struct lsa_CreateTrustedDomainEx2
        out: struct lsa_CreateTrustedDomainEx2
            trustdom_handle          : *
                trustdom_handle: struct policy_handle
                    handle_type              : 0x00000000 (0)
                    uuid                     : 00000000-0000-0000-0000-000000000000
            result                   : NT_STATUS_ACCESS_DENIED
rpc reply data:
[0000] 00 00 00 00 00 00 00 00   00 00 00 00 00 00 00 00   ........ ........
[0010] 00 00 00 00 22 00 00 C0                            ...."... 
[Thu Jul 25 17:14:36 2013] [error] ipa: INFO: trust.admin: trust_add(u'testdave.com', trust_type=u'ad', realm_admin=u'james.findley.a', realm_passwd=u'********', base_id=791200000, range_size=200000, all=True, raw=False, version=u'2.46'): ACIError
[Thu Jul 25 17:14:36 2013] [error] ipa: DEBUG: response: ACIError: Insufficient access: Gettext('CIFS server denied your credentials', domain='ipa', localedir=None)


Adding Alexander and Sumit to CC to advise.
Comment 4 Alexander Bokovoy 2013-07-26 07:23:26 UTC 
I actually worked yesterday with James on IRC and we got through this issue. The original issue was that Samba uses special RID 512 (Domain Admins) to control access to privileged operations. We assign RID 512 to 'admins' group and require that a user who manages trusted domains to be in 'trust admins' groups. However, 'trust admins' group does not have SID assigned, so to Samba it is invisible and if your admin user is member of 'trust admins' but isn't member of 'admins' group, you don't get Domain Admins privileges.

In James' case situation was complicated by the fact that his 'admins' group also lacked RID 512. In fact, his users lacked any SIDs so MS-PAC was not issued for them. After fixing that manually he was able to complete establishing trust.

I've asked James to file this bug to allow us to define properly access controls for 'trust admins' group and recognize it from Samba side. I think we either need to mark it as Enterprise Admins (and add support for Enterprise Admins privileges in Samba) or make sure 'trust admins' membership brings in RID 512 membership.

Adding Simo to CC: to get his opinion.
Comment 5 Simo Sorce 2013-07-30 11:18:02 UTC 
We can also add a privilege to samba and make sure the Trusted Admins group has a SID AND the privilege. But yeah at the very least the Trusted Admin group needs a SID and that SID neds to be made so samba will trate it as allowed to create trusted domains.
Comment 6 Martin Kosek 2013-07-30 15:34:06 UTC 
Ok, I will clone to FreeIPA upstream to get SID to Trust Admins group as well.
Comment 7 Martin Kosek 2013-07-31 15:35:22 UTC 
Upstream ticket:
https://fedorahosted.org/freeipa/ticket/3828
Comment 8 Martin Kosek 2013-08-02 07:54:50 UTC 
We discussed this bug with Alexander again and decided to move it to RHEL-7 product as the fix is not straightforward and requires changes to both ipa and samba components.
Comment 9 Martin Kosek 2013-08-06 12:57:33 UTC 
Adding needinfo? for Alexander to provide Known Issue doc text for RHEL-7.0.
Comment 10 Alexander Bokovoy 2013-12-04 20:35:16 UTC 
Added documentation text.
Comment 21 Alexander Bokovoy 2019-07-04 13:26:36 UTC 
Closing as UPSTREAM: freeipa-healthcheck now includes a check to validate that admins' group SID ends with RID 512  (Domain Admins RID).