Hide Forgot
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.
Created attachment 778389 [details] httpd logs
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.
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.
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.
Ok, I will clone to FreeIPA upstream to get SID to Trust Admins group as well.
Upstream ticket: https://fedorahosted.org/freeipa/ticket/3828
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.
Adding needinfo? for Alexander to provide Known Issue doc text for RHEL-7.0.
Added documentation text.
Closing as UPSTREAM: freeipa-healthcheck now includes a check to validate that admins' group SID ends with RID 512 (Domain Admins RID).