Hi,
We have a three node Centos 8 IPA domain which we upgraded from Centos 8.3 to 8.4 (IPA version 4.9.2) yesterday. This appeared to succeed without issue, with clients continuing to operate as expected. To give us confidence that all was well we ran ipa-healthcheck on each node post upgrade and this found no issues on our two client facing servers ipa0 and ipa1 but on the third machine, ipa2, which is configured as a hidden replica (and is used to take disaster recovery backups) we received the following error:
[ { "source": "ipahealthcheck.ipa.trust", "check": "IPATrustControllerServiceCheck", "result": "ERROR", "uuid": "f5d524a3-43c3-4320-92cb-c984727243d9", "when": "20210624085009Z", "duration": "0.000512", "kw": { "key": "ADTRUST", "msg": "{key} service is not enabled" } } ]
We have Samba services setup for Centos based SMB file sharing - there is no Active Directory install on our network.
Is this error a concern or is it a consequence of being a hidden replica. If it is a problem, how might we go about fixing the issue? As a first step I've tried re-running ipa-adtrust and this didn't seem to need to make any changes:
The log file for this installation can be found in /var/log/ipaserver-adtrust-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
The following operations may take some minutes to complete. Please wait until the prompt is returned.
Configuring CIFS [1/24]: validate server hostname [2/24]: stopping smbd [3/24]: creating samba domain object Samba domain object already exists [4/24]: retrieve local idmap range [5/24]: writing samba config file [6/24]: creating samba config registry [7/24]: adding cifs Kerberos principal [8/24]: adding cifs and host Kerberos principals to the adtrust agents group [9/24]: check for cifs services defined on other replicas [10/24]: adding cifs principal to S4U2Proxy targets cifs principal already targeted, nothing to do. [11/24]: adding admin(group) SIDs Admin SID already set, nothing to do Admin group SID already set, nothing to do [12/24]: adding RID bases RID bases already set, nothing to do [13/24]: updating Kerberos config 'dns_lookup_kdc' already set to 'true', nothing to do. [14/24]: activating CLDAP plugin CLDAP plugin already configured, nothing to do [15/24]: activating sidgen task Sidgen task plugin already configured, nothing to do [16/24]: map BUILTIN\Guests to nobody group [17/24]: configuring smbd to start on boot [18/24]: enabling trusted domains support for older clients via Schema Compatibility plugin [19/24]: restarting Directory Server to take MS PAC and LDAP plugins changes into account [20/24]: adding fallback group Fallback group already set, nothing to do [21/24]: adding Default Trust View Default Trust View already exists. [22/24]: setting SELinux booleans [23/24]: starting CIFS services [24/24]: 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
=============================================================================
But there is no change in ipahealthcheck output.
Regards,
Duncan
Duncan Mortimer via FreeIPA-users wrote:
Hi,
We have a three node Centos 8 IPA domain which we upgraded from Centos 8.3 to 8.4 (IPA version 4.9.2) yesterday. This appeared to succeed without issue, with clients continuing to operate as expected. To give us confidence that all was well we ran ipa-healthcheck on each node post upgrade and this found no issues on our two client facing servers ipa0 and ipa1 but on the third machine, ipa2, which is configured as a hidden replica (and is used to take disaster recovery backups) we received the following error:
[ { "source": "ipahealthcheck.ipa.trust", "check": "IPATrustControllerServiceCheck", "result": "ERROR", "uuid": "f5d524a3-43c3-4320-92cb-c984727243d9", "when": "20210624085009Z", "duration": "0.000512", "kw": { "key": "ADTRUST", "msg": "{key} service is not enabled" } } ]
We have Samba services setup for Centos based SMB file sharing - there is no Active Directory install on our network.
Is this error a concern or is it a consequence of being a hidden replica. If it is a problem, how might we go about fixing the issue? As a first step I've tried re-running ipa-adtrust and this didn't seem to need to make any changes:
The log file for this installation can be found in /var/log/ipaserver-adtrust-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
The following operations may take some minutes to complete. Please wait until the prompt is returned.
Configuring CIFS [1/24]: validate server hostname [2/24]: stopping smbd [3/24]: creating samba domain object Samba domain object already exists [4/24]: retrieve local idmap range [5/24]: writing samba config file [6/24]: creating samba config registry [7/24]: adding cifs Kerberos principal [8/24]: adding cifs and host Kerberos principals to the adtrust agents group [9/24]: check for cifs services defined on other replicas [10/24]: adding cifs principal to S4U2Proxy targets cifs principal already targeted, nothing to do. [11/24]: adding admin(group) SIDs Admin SID already set, nothing to do Admin group SID already set, nothing to do [12/24]: adding RID bases RID bases already set, nothing to do [13/24]: updating Kerberos config 'dns_lookup_kdc' already set to 'true', nothing to do. [14/24]: activating CLDAP plugin CLDAP plugin already configured, nothing to do [15/24]: activating sidgen task Sidgen task plugin already configured, nothing to do [16/24]: map BUILTIN\Guests to nobody group [17/24]: configuring smbd to start on boot [18/24]: enabling trusted domains support for older clients via Schema Compatibility plugin [19/24]: restarting Directory Server to take MS PAC and LDAP plugins changes into account [20/24]: adding fallback group Fallback group already set, nothing to do [21/24]: adding Default Trust View Default Trust View already exists. [22/24]: setting SELinux booleans [23/24]: starting CIFS services [24/24]: 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
=============================================================================
But there is no change in ipahealthcheck output.
This particular check is only run on trust controllers, those machines with the server role of AD trust controller. (ipa server-role-show <hostname> 'AD trust controller')
It makes sure that the ADTRUST service is marked as enabled, so that the services will be started by ipactl (smb).
You can see it with:
kinit admin ldapsearch -Y GSSAPI -b cn=ADTRUST,cn=`hostname`,cn=masters,cn=ipa,cn=etc,dc=example,dc=test
So since it's a trust server and doesn't have ADTRUST enabled it means that ipactl won't manage smb.
Now given your use case it's possible this is a false positive. Alexander, what do you think?
rob
On to, 24 kesä 2021, Rob Crittenden wrote:
But there is no change in ipahealthcheck output.
This particular check is only run on trust controllers, those machines with the server role of AD trust controller. (ipa server-role-show <hostname> 'AD trust controller')
It makes sure that the ADTRUST service is marked as enabled, so that the services will be started by ipactl (smb).
You can see it with:
kinit admin ldapsearch -Y GSSAPI -b cn=ADTRUST,cn=`hostname`,cn=masters,cn=ipa,cn=etc,dc=example,dc=test
So since it's a trust server and doesn't have ADTRUST enabled it means that ipactl won't manage smb.
Now given your use case it's possible this is a false positive. Alexander, what do you think?
ADTRUST service should be present and active if ipa-adtrust-install was run. If it doesn't that's an error and ipa-healthcheck highlights it correctly.
Hi,
LDAP search on the node in question results in the following.
ldapsearch -Y GSSAPI -b cn=ADTRUST,cn=`hostname`,cn=masters,cn=ipa,cn=etc,dc=my,dc=domain SASL/GSSAPI authentication started SASL username: admin@IPA.my.domain SASL SSF: 256 SASL data security layer installed. # extended LDIF # # LDAPv3 # base <cn=ADTRUST,cn=ipa2.my.domain,cn=masters,cn=ipa,cn=etc,dc=my,dc=domain> with scope subtree # filter: (objectclass=*) # requesting: ALL #
# ADTRUST, ipa2.my.domain, masters, ipa, etc, my.domain dn: cn=ADTRUST,cn=ipa2.my.domain,cn=masters,cn=ipa,cn=etc,dc=my,dc=domain objectClass: nsContainer objectClass: ipaConfigObject objectClass: top cn: ADTRUST ipaConfigString: startOrder 60 ipaConfigString: hiddenService
# search result search: 4 result: 0 Success
# numResponses: 2 # numEntries: 1
If this isn’t a false positive, what steps should I take to try to resolve this?
Regards,
Duncan
Thanks for this. It's a bug in freeipa-healthcheck. I opened https://github.com/freeipa/freeipa-healthcheck/issues/217
Unfortunately other than removing the server as a hidden server there is no workaround other than to ignore the false positive until a new build can be made.
rob
Duncan Mortimer wrote:
Hi,
LDAP search on the node in question results in the following.
ldapsearch -Y GSSAPI -b cn=ADTRUST,cn=`hostname`,cn=masters,cn=ipa,cn=etc,dc=my,dc=domain SASL/GSSAPI authentication started SASL username: admin@IPA.my.domain SASL SSF: 256 SASL data security layer installed. # extended LDIF # # LDAPv3 # base <cn=ADTRUST,cn=ipa2.my.domain,cn=masters,cn=ipa,cn=etc,dc=my,dc=domain> with scope subtree # filter: (objectclass=*) # requesting: ALL #
# ADTRUST, ipa2.my.domain, masters, ipa, etc, my.domain dn: cn=ADTRUST,cn=ipa2.my.domain,cn=masters,cn=ipa,cn=etc,dc=my,dc=domain objectClass: nsContainer objectClass: ipaConfigObject objectClass: top cn: ADTRUST ipaConfigString: startOrder 60 ipaConfigString: hiddenService
# search result search: 4 result: 0 Success
# numResponses: 2 # numEntries: 1
If this isn’t a false positive, what steps should I take to try to resolve this?
Regards,
Duncan
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
Duncan Mortimer -
Rob Crittenden