Created attachment 1971942 [details] log files Description of problem: RHEL 8.8 & 9.2 fails to create AD trust with STIG applied. Version-Release number of selected component (if applicable): RHEL 8.8 and 9.2 How reproducible: consistent Steps to Reproduce: 1. Install OS with DISA STIG security profile 2. Install IdM 3. Create trust 3a. ipa trust-add --type=ad <ad domain> Actual results: body: b'{"result": null, "error": {"code": 4016, "message": "CIFS server communication error: code \\"3221225581\\", message \\"The attempted logon is invalid. This is either due to a bad username or authentication information.\\" (both may be \\"None\\")", "data": {"reason": "CIFS server communication error: code \\"3221225581\\", message \\"The attempted logon is invalid. This is either due to a bad username or authentication information.\\" (both may be \\"None\\")"}, "name": "RemoteRetrieveError"}, "id": 0, "principal": "admin.COM", "version": "4.9.11"}' ipa: INFO: Response: { "error": { "code": 4016, "data": { "reason": "CIFS server communication error: code \"3221225581\", message \"The attempted logon is invalid. This is either due to a bad username or authentication information.\" (both may be \"None\")" }, "message": "CIFS server communication error: code \"3221225581\", message \"The attempted logon is invalid. This is either due to a bad username or authentication information.\" (both may be \"None\")", "name": "RemoteRetrieveError" }, "id": 0, "principal": "admin.COM", "result": null, "version": "4.9.11" } ipa: ERROR: CIFS server communication error: code "3221225581", message "The attempted logon is invalid. This is either due to a bad username or authentication information." (both may be "None") Expected results: Trust is created Additional info: DISA STIG applied during OS install and FIPS removed before IdM installation.
Moving back to ipa. The issue happens because there is an existing sssd.conf file pre-installation, that does not contain [sssd] services=nss, pam File before installation: # cat /etc/sssd/sssd.conf [sssd] domains = default [domain/default] id_provider = files [pam] pam_cert_auth = True offline_credentials_expiration = 1 In the usual case, there is no /etc/sssd/sssd.conf file when ipa-server-install is called and the installer creates the file using import SSSDConfig sssdconfig = SSSDConfig.SSSDConfig() sssdconfig.new_config() In this case, the new object sssdconfig has some services activated by default: sssdconfig.list_active_services() ['nss', 'pam'] In the STIG case, there is already a /etc/sssd/sssd.conf file before ipa-server-install is called and the installer goes in a different code path: import SSSDConfig sssdconfig = SSSDConfig.SSSDConfig() sssdconfig.import_config() The code configure the options for the server but never tries to activate the service, while it should using sssdconfig.activate_service('nss'). Relevant code portion: https://github.com/freeipa/freeipa/blob/a9ee2adec38b23d7d957d503d79e20b2174cc512/ipaclient/install/client.py#L964-L970 try: nss_service = sssdconfig.get_service('nss') except SSSDConfig.NoServiceError: nss_service = sssdconfig.new_service('nss') nss_service.set_option('memcache_timeout', 600) sssdconfig.save_service(nss_service)
Upstream ticket: https://pagure.io/freeipa/issue/9427
Fixed upstream master: https://pagure.io/freeipa/c/7796b7b9585e9459bb44b8ea92c50eb2592319cf
Fixed upstream ipa-4-10: https://pagure.io/freeipa/c/4a62a21499a4884f0db55d01966a6ff532a4ed1e ipa-4-9: https://pagure.io/freeipa/c/f38eefd9f7e54470de7c707782114b17aac8762a