Bug 1250107 - IPA framework should not allow modifying trust on AD trust agents
IPA framework should not allow modifying trust on AD trust agents
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipa (Show other bugs)
7.2
Unspecified Unspecified
medium Severity unspecified
: rc
: ---
Assigned To: IPA Maintainers
Namita Soman
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-04 10:19 EDT by Jan Cholasta
Modified: 2015-11-19 07:04 EST (History)
4 users (show)

See Also:
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 07:04:56 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jan Cholasta 2015-08-04 10:19:51 EDT
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@EXAMPLE.COM: 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 07:35:24 EDT
Could you please add steps to verify this bug?
Comment 4 Martin Bašti 2015-10-12 09:22:45 EDT
Tomas is author
Comment 5 Tomas Babej 2015-10-13 08:34:25 EDT
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 09:32:10 EDT
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 07:04:56 EST
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

Note You need to log in before you can comment on or make changes to this bug.