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 1252414 - Trust agent install does not detect available replicas to add to master
Summary: Trust agent install does not detect available replicas to add to master
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipa
Version: 7.2
Hardware: x86_64
OS: Linux
medium
unspecified
Target Milestone: rc
: ---
Assignee: IPA Maintainers
QA Contact: Namita Soman
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-08-11 10:56 UTC by Varun Mylaraiah
Modified: 2015-11-19 12:05 UTC (History)
3 users (show)

Fixed In Version: ipa-4.2.0-4.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-11-19 12:05:13 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:2362 0 normal SHIPPED_LIVE ipa bug fix and enhancement update 2015-11-19 10:40:46 UTC

Description Varun Mylaraiah 2015-08-11 10:56:25 UTC 
Description of problem:
=======================
"ipa-adtrust-install --add-agents" command fails to identify the available replica's (installed replica's) to be added to the master.


ipa version:
=============
ipa-server-4.2.0-3.el7.x86_64
sssd-1.13.0-11.el7.x86_64


Additional info:
================
Discussed with Ab about this behavior via email. Please find below his response and possible fix to address this issue.
Ab's response (root cause analysis):
===================================
AD Trust agents feature requires RHEL7.2 masters for the agents' side.
We cannot enable older masters as they wouldn't have proper SSSD and
proper IPA to work in such mode. To do filtration of the older/newer
masters, we rely on the following filter:

"(&(objectclass=ipaSupportedDomainLevelConfig)(!(ipaMaxDomainLevel=0)))"

e.g. these should be masters which records have object class for
topology plugin and configured to serve topology plugin. If only
objectclass is there, it might simply be a replica that got
configuration but no actual code from FreeIPA 4.2.

What has happened with IPA in RHEL7.2 is that we decided to not enable
topology plugin until its functionality will be full. As result, the
filter above is not giving any output because all replicas now have
ipaMaxDomainLevel equal to 0:

# replica1.btestrelm.test, masters, ipa, etc, btestrelm.test
dn: cn=replica1.btestrelm.test,cn=masters,cn=ipa,cn=etc,dc=btestrelm,dc=test
objectClass: top
objectClass: nsContainer
objectClass: ipaReplTopoManagedServer
objectClass: ipaConfigObject
objectClass: ipaSupportedDomainLevelConfig
cn: replica1.btestrelm.test
ipaReplTopoManagedSuffix: dc=btestrelm,dc=test
ipaMinDomainLevel: 0
ipaMaxDomainLevel: 0


We need to find out any other way to differentiate between new and old
replicas and change the filter accordingly.

Ab's Proposed Idea to fix the issue:
====================================
We need to get list of those IPA replicas which run IPA 4.2, unrelated
to whether they were configured with ipa-adtrust-install or not. We need
to know that master was upgraded to 4.2, reliably.

That said, we add ipaMinDomainLevel/ipaMaxDomainLevel in 72-domainlevels.update
which means you have to update your replica to actually receive these
values in your replica's entry. We could simply change the filter to
make sure that both attributes exist and don't care about the value.

I tried to change the filter in ipa-adtrust-install to 

filter="(&(objectclass=ipaSupportedDomainLevelConfig)(ipaMaxDomainLevel=*)(ipaMinDomainLevel=*))",

and it detected there are three replicas to add agents on.
Comment 3 Petr Vobornik 2015-08-11 13:33:58 UTC 
Upstream ticket:
https://fedorahosted.org/freeipa/ticket/5199
Comment 4 Jan Cholasta 2015-08-11 15:00:11 UTC 
Fixed upstream
master:
https://fedorahosted.org/freeipa/changeset/1fc21e980bb901bf71f7ee024cdbb15c1caec3a7
ipa-4-2:
https://fedorahosted.org/freeipa/changeset/ef192fb17be348c526029e8fa5165b9108e1f6da
Comment 6 Varun Mylaraiah 2015-08-17 11:29:31 UTC 
Verified 

ipa version:
=============
ipa-server-4.2.0-4.el7.x86_64

"ipa-adtrust-install --add-agents" command now identify the available replica's.




[root@master1 ~]# ipa-adtrust-install --add-agents 

The log file for this installation can be found in /var/log/ipaserver-install.log
==============================================================================
This program will setup components needed to establish trust to AD domains for
the IPA Server.

This includes:
  * Configure Samba
  * Add trust related objects to IPA LDAP server

To accept the default shown in brackets, press the Enter key.

IPA generated smb.conf detected.
Overwrite smb.conf? [no]: yes
Do you want to enable support for trusted domains in Schema Compatibility plugin?
This will allow clients older than SSSD 1.9 and non-Linux clients to work with trusted users.

Enable trusted domains support in slapi-nis? [no]: y

Configuring cross-realm trusts for IPA server requires password for user 'admin'.
This user is a regular system account used for IPA server administration.

admin password: 


The following operations may take some minutes to complete.
Please wait until the prompt is returned.

Configuring CIFS
  [1/22]: stopping smbd
  [2/22]: creating samba domain object
Samba domain object already exists
  [3/22]: creating samba config registry
  [4/22]: writing samba config file
  [5/22]: adding cifs Kerberos principal
  [6/22]: adding cifs and host Kerberos principals to the adtrust agents group
  [7/22]: check for cifs services defined on other replicas
  [8/22]: adding cifs principal to S4U2Proxy targets
cifs principal already targeted, nothing to do.
  [9/22]: adding admin(group) SIDs
Admin SID already set, nothing to do
Admin group SID already set, nothing to do
  [10/22]: adding RID bases
RID bases already set, nothing to do
  [11/22]: updating Kerberos config
'dns_lookup_kdc' already set to 'true', nothing to do.
  [12/22]: activating CLDAP plugin
CLDAP plugin already configured, nothing to do
  [13/22]: activating sidgen task
Sidgen task plugin already configured, nothing to do
  [14/22]: configuring smbd to start on boot
  [15/22]: adding special DNS service records
  [16/22]: enabling trusted domains support for older clients via Schema Compatibility plugin
  [17/22]: restarting Directory Server to take MS PAC and LDAP plugins changes into account
  [18/22]: adding fallback group
Fallback group already set, nothing to do
  [19/22]: adding Default Trust View
Default Trust View already exists.
  [20/22]: setting SELinux booleans
  [21/22]: enabling oddjobd
  [22/22]: starting CIFS services
Done configuring CIFS.

WARNING: 1 IPA masters are not yet able to serve information about users from trusted forests.
Installer can add them to the list of IPA masters allowed to access infromation about trusts.
If you choose to do so, you also need to restart LDAP service on those masters.
Refer to ipa-adtrust-install(1) man page for details.

Do you want to allow following IPA masters to serve information about users from trusted forests?
IPA master [replica2.btestrelm.test]? [no]:
Comment 7 errata-xmlrpc 2015-11-19 12:05:13 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
Note You need to log in before you can comment on or make changes to this bug.