Hello, I have two FreeIPA servers with AD trust enabled. Usually I do everything on the IPA #1 server, but I just observed that SIDs aren’t resolved on the replica, is it normal? I’m attaching a picture of the issue to illustrate it. If this is not right, someone can help with debugging steps? I observed that I can’t do getent passwd ferrao on the replica either. Only on master: [root@ipa1 ~]# getent passwd ferrao [1]ferrao@ad.example.com:*:1499401105:1499401105:Vinícius Ferrão:/home/ferrao: [root@ipa2 ~]# getent passwd ferrao

Hi Alexander, But is it ok to not being controller trust or trust agent? It’s a good idea to be a trust agent at least? How can I check both?

I can fetch from IPA the data regarding the trust, on the replica server normally. [root@ipa2 ~]# ipa trust-show Realm name: ad.example.com Realm name: ad.example.com Domain NetBIOS name: EXAMPLE Domain Security Identifier: S-1-5-21-3644117338-1171143469-618167831 Trust direction: Trusting forest Trust type: Active Directory domain UPN suffixes: example.com, invalid.com [root@ipa2 ~]# ipa trustdomain-find Realm name: ad.example.com Domain name: ad.example.com Domain NetBIOS name: EXAMPLE Domain Security Identifier: S-1-5-21-3644117338-1171143469-618167831 Domain enabled: True Thank you. > On 3 Jul 2020, at 04:20, Alexander Bokovoy <abokovoy(a)redhat.com&gt; wrote: > > On pe, 03 heinä 2020, Vinícius Ferrão via FreeIPA-users wrote: >> Hello, I have two FreeIPA servers with AD trust enabled. Usually I do everything on the IPA #1 server, but I just observed that SIDs aren’t resolved on the replica, is it normal? I’m attaching a picture of the issue to illustrate it. If this is not right, someone can help with debugging steps? I observed that I can’t do getent passwd ferrao on the replica either. Only on master: [root@ipa1 ~]# getent passwd ferrao [1]ferrao@ad.example.com:*:1499401105:1499401105:Vinícius Ferrão:/home/ferrao: [root@ipa2 ~]# getent passwd ferrao > > Looks like the second server is neither trust controller nor trust > agent. > > -- > / Alexander Bokovoy > Sr. Principal Software Engineer > Security / Identity Management Engineering > Red Hat Limited, Finland >

Hi again Alexander, On 3 Jul 2020, at 04:47, Alexander Bokovoy <[1]abokovoy(a)redhat.com&gt; wrote: On pe, 03 heinä 2020, Vinícius Ferrão wrote: Hi Alexander, But is it ok to not being controller trust or trust agent? It’s a good idea to be a trust agent at least? How can I check both? 'trust agent' is IPA server which resolves AD users and groups. So if you want your IPA clients to resolve AD users and groups, it needs to talk to a master/replica with "Trust Agent' server role. However, resolution of SIDs in web UI and IPA CLI requires that a master/replica you talk to has 'freeipa-server-trust-ad' package installed because that one pulls in actual required packages that allow us to resolve SIDs from Python. That has an overhead of installing all Samba components, inclulding server side. This is not an issue, since the packages are already there. It's fine :) If you don't want that, you might want to install only  python3-libsss_nss_idmap python3-samba python3-sss They are already installed on both servers: python3-sss-murmur-2.2.3-20.el8.x86_64 python3-libsss_nss_idmap-2.2.3-20.el8.x86_64 python3-sss-2.2.3-20.el8.x86_64 python3-samba-4.11.2-13.el8.x86_64 python3-sssdconfig-2.2.3-20.el8.noarch addition to python3-ipaserver and make the host 'Trust agent'. I haven't checked that this recipe indeed works, only validated the dependencies. 'trust controller' is what makes possible to establish trust to AD forest. You don't need more than one of those, typically. Ok! I’ll follow the path you recommend with two trust agents and one trust controller. But what I don’t get is that I think something in broken in the replica. You see, the packages are already there, ipa-server-trust-ad-4.8.4 are installed on both servers and on ipa2 this problem happens. Anyway I tried to add the agent, but it changed nothing: # 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. 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:  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]:  The following operations may take some minutes to complete. Please wait until the prompt is returned. Configuring CIFS   [1/23]: validate server hostname   [2/23]: stopping smbd   [3/23]: creating samba domain object Samba domain object already exists   [4/23]: retrieve local idmap range   [5/23]: creating samba config registry   [6/23]: writing samba config file   [7/23]: adding cifs Kerberos principal   [8/23]: adding cifs and host Kerberos principals to the adtrust agents group   [9/23]: check for cifs services defined on other replicas   [10/23]: adding cifs principal to S4U2Proxy targets cifs principal already targeted, nothing to do.   [11/23]: adding admin(group) SIDs Admin SID already set, nothing to do Admin group SID already set, nothing to do   [12/23]: adding RID bases RID bases already set, nothing to do   [13/23]: updating Kerberos config 'dns_lookup_kdc' already set to 'true', nothing to do.   [14/23]: activating CLDAP plugin CLDAP plugin already configured, nothing to do   [15/23]: activating sidgen task Sidgen task plugin already configured, nothing to do   [16/23]: map BUILTIN\Guests to nobody group   [17/23]: configuring smbd to start on boot   [18/23]: restarting Directory Server to take MS PAC and LDAP plugins changes into account   [19/23]: adding fallback group Fallback group already set, nothing to do   [20/23]: adding Default Trust View Default Trust View already exists.   [21/23]: setting SELinux booleans   [22/23]: starting CIFS services   [23/23]: restarting smbd Done configuring CIFS. ============================================================================= Setup complete You must make sure these network ports are open: TCP Ports:   * 135: epmap   * 138: netbios-dgm   * 139: netbios-ssn   * 445: microsoft-ds   * 1024..1300: epmap listener range   * 3268: msft-gc UDP Ports:   * 138: netbios-dgm   * 139: netbios-ssn   * 389: (C)LDAP   * 445: microsoft-ds See the ipa-adtrust-install(1) man page for more details ============================================================================= I’ve run the command on both servers, and the output was exactly the same. I even rebooted IPA2 “just in case”. Any ideias?

                                                       [root@ipa1 ~]# getent passwd ferrao      ferrao@ad.example.com:*:1499401105:1499401105:Vinícius Ferrão:/home/ferrao:            [root@ipa2 ~]# getent passwd ferrao

As you can see randomuser1 wasn’t being detected, then it recognised after a full UPN query. I’m guessing it may be related with what you said about the default domain order. > Also I noticed this: > >> [root@ipa1 ~]# getent passwd ferrao ferrao@ad.example.com:*:1499401105:1499401105:Vinícius Ferrão:/home/ferrao: [root@ipa2 ~]# getent passwd ferrao > > We do not support unqualified AD user and group names on IPA masters. > > Please remove the corresponding setting from SSSD or default domain > order in IPA. This messes up quite a lot things. My default domain was set with: nix.example.com:ad.example.com This isn’t supported? I added AD as the second domain so ssh to the machines would be easier. If I need to remove it, and want to keep just the login to ease login on Unix machine I should do exactly I’ve done with the home directories? With a per-user ID override?

> I guess as long as you are using fully qualified AD users/groups names > on IPA masters, you don't need to remove the setting. Ok! Thank you. I’ll do some testing to see if the strange behaviour of getent will be solved removing the AD domain from default domain order. If there’s a way to undo the messing on the replica, removing the second trust controller, please let me know.