Bug 1250107

Summary: IPA framework should not allow modifying trust on AD trust agents
Product: Red Hat Enterprise Linux 7 Reporter: Jan Cholasta <jcholast>
Component: ipaAssignee: IPA Maintainers <ipa-maint>
Status: CLOSED ERRATA QA Contact: Namita Soman <nsoman>
Severity: unspecified Docs Contact:
Priority: medium    
Version: 7.2CC: mbasti, mvarun, rcritten, tbabej
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: ipa-4.2.0-5.el7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-11-19 12:04:56 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jan Cholasta 2015-08-04 14:19:51 UTC
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/freeipa/ticket/5165

With FreeIPA 4.2, IPA replicas can serve AD users and groups without being able to set up or modifying trust properties. In case of AD trust agent, such IPA replica didn't have ipa-adtrust-install executed and no Samba instance is running.

'ipa trust-add' and other commands expect they are able to communicate with locally running Samba instance for setting up trust. If it is not running, we currently get exception that should be properly detected and instead a message should be shown to use different IPA master (where ipa-adtrust-install) was set up.

{{{
INFO: Current debug levels:
  all: 100
  tdb: 100
  printdrivers: 100
  lanman: 100
  smb: 100
  rpc_parse: 100
  rpc_srv: 100
  rpc_cli: 100
  passdb: 100
  sam: 100
  auth: 100
  winbind: 100
  vfs: 100
  idmap: 100
  quota: 100
  acls: 100
  locking: 100
  msdfs: 100
  dmapi: 100
  registry: 100
  scavenger: 100
  dns: 100
  ldb: 100
pm_process() returned Yes
Using binding ncacn_np:m2.example.com[,print,smb2]
s4_tevent: Added timed event "dcerpc_connect_timeout_handler": 0x7ffab403e600
s4_tevent: Added timed event "composite_trigger": 0x7ffab403edd0
s4_tevent: Added timed event "composite_trigger": 0x7ffab403f010
s4_tevent: Running timer event 0x7ffab403edd0 "composite_trigger"
s4_tevent: Destroying timer event 0x7ffab403f010 "composite_trigger"
Mapped to DCERPC endpoint \pipe\lsarpc
added interface eth0 ip=192.168.122.107 bcast=192.168.122.255 netmask=255.255.255.0
added interface eth0 ip=192.168.122.107 bcast=192.168.122.255 netmask=255.255.255.0
resolve_lmhosts: Attempting lmhosts lookup for name m2.example.com<0x20>
getlmhostsent: lmhost entry: 127.0.0.1 localhost 
s4_tevent: Added timed event "composite_trigger": 0x7ffab40409a0
s4_tevent: Ending timer event 0x7ffab403edd0 "composite_trigger"
s4_tevent: Running timer event 0x7ffab40409a0 "composite_trigger"
s4_tevent: Added timed event "connect_multi_timer": 0x7ffab4040c70
s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7ffab4041210
s4_tevent: Run immediate event "tevent_req_trigger": 0x7ffab4041210
s4_tevent: Destroying timer event 0x7ffab4040c70 "connect_multi_timer"
Socket options:
        SO_KEEPALIVE = 0
        SO_REUSEADDR = 0
        SO_BROADCAST = 0
        TCP_NODELAY = 1
        TCP_KEEPCNT = 9
        TCP_KEEPIDLE = 7200
        TCP_KEEPINTVL = 75
        IPTOS_LOWDELAY = 0
        IPTOS_THROUGHPUT = 0
        SO_REUSEPORT = 0
        SO_SNDBUF = 16384
        SO_RCVBUF = 87380
        SO_SNDLOWAT = 1
        SO_RCVLOWAT = 1
        SO_SNDTIMEO = 0
        SO_RCVTIMEO = 0
        TCP_QUICKACK = 1
        TCP_DEFER_ACCEPT = 0
s4_tevent: Destroying timer event 0x7ffab403e600 "dcerpc_connect_timeout_handler"
[Fri Jul 24 13:15:28.747820 2015] [wsgi:error] [pid 31306] ipa: INFO: [jsonserver_kerb] admin: trust_add(u'adx.test', trust_type=u'ad', realm_admin=u'Administrator', realm_passwd=u'********', all=False, raw=False, version=u'2.147'): RemoteRetrieveError
}}}

Comment 3 Varun Mylaraiah 2015-10-12 11:35:24 UTC
Could you please add steps to verify this bug?

Comment 4 Martin Bašti 2015-10-12 13:22:45 UTC
Tomas is author

Comment 5 Tomas Babej 2015-10-13 12:34:25 UTC
This bug is about detecting whether it makes sense to run trust-related commands on a server. If it does not (samba is not installed) a helpful message is provided instead, referring to the servers that are capable of performing the required command.

Steps therefore are:
1. install ipa server
2. install adtrust on it
3. install a replica
4. run a trust related (trust-add, trust-fetch-domains) command on the replica

Your action should be denied and a helpful message referring you to the original IPA server should be provided.

Comment 6 Varun Mylaraiah 2015-10-13 13:32:10 UTC
Verified.
ipa-server-4.2.0-13.el7.x86_64


[root@replica ~]# ipa trust-find
---------------
1 trust matched
---------------
  Realm name: adlabs.com
  Domain NetBIOS name: ADLABS
  Domain Security Identifier: S-1-5-21-3069109027-1612402048-776712048
  Trust type: Active Directory domain
----------------------------
Number of entries returned 1
----------------------------
[root@replica ~]# 
[root@replica ~]# 
[root@replica ~]# 
[root@replica ~]# echo Secret123|ipa trust-add --type=ad adlabs.com --admin Administrator --password
ipa: ERROR: Cannot perform the selected command without Samba 4 support installed. Make sure you have installed server-trust-ad sub-package of IPA. Alternatively, following servers are capable of running this command: master2.dtestrelm.test

Comment 7 errata-xmlrpc 2015-11-19 12:04:56 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2362.html