Bug 2260368

Summary: Satellite SSO Integration With Active Directory using GSSPROXY
Product: Red Hat Satellite Reporter: klwilson78
Component: AuthenticationAssignee: Aneta Šteflová Petrová <apetrova>
Status: CLOSED MIGRATED QA Contact: Satellite QE Team <sat-qe-bz-list>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.14.0CC: alazik, alsouza, apetrova, mhulan
Target Milestone: 6.14.2Keywords: Documentation, MigratedToJIRA, Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2024-06-06 17:00:43 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description klwilson78 2024-01-25 17:20:02 UTC 
Document URL: https://access.redhat.com/documentation/en-us/red_hat_satellite/6.14/html-single/installing_satellite_server_in_a_connected_network_environment/index#Configuring_Direct_AD_Integration_with_GSS_Proxy_satellite

Section Number and Name: 

5.3 Configuring Direct AD Integration with GSS-Proxy

Describe the issue: 

Red Hat documentation states: "The traditional process of Kerberos authentication in Apache requires the Apache process to have read access to the keytab file. GSS-Proxy allows you to implement stricter privilege separation for the Apache server by removing access to the keytab file while preserving Kerberos authentication functionality"

However, the instructions then direct the user to place the keytab file in an apache config directory '/etc/httpd/conf'. Doing so give the keytab file an SELinux context of httpd_config_t. This will cause all sorts of SELinux errors since gssproxy will be denied access to the file. The documentation never mentions the SELinux context of the file. Furthermore, the documentation instructs the user to set the group owner of the file to apache, and to give the group read access. This gives the apache user read access to the keytab file, which is the exact oppposite of the purpose for using gssproxy as stated above in the documentation.

Additionally, following the documentation will not result in a working SSO set up using Kerberos, because a Service Principal Name (SPN) must be created in Active Directory in order for Kerberos to work. At no point does the documentation mention creating the "HTTP/servername.example.com" SPN in AD. 

Suggestions for improvement: 

Move the keytab file to /etc/gssproxy and set the context on the file to krb5_keytab_t. Set the ownership on the keytab file to root.root and the permissions to 600. Apache should not have access. Update the path in the '/etc/gssproxy/00-http.conf' file to point to the new keytab location.

Instruct the user on how to create the necessary SPN in active directory, either from windows using the setspn command, or from Linux using the adcli command or via another method. Without this step, Kerberos authentication will fail.

Make it clear that the expected behavior of the browser is not to attempt Kerberos authentication when using the server FQDN unless the hostname has been included in the browser's defined "Local intranet" zone.

Additional information:
Comment 1 Marie Hornickova 2024-01-30 08:49:19 UTC 
Hello,
many thanks for reporting this suggestion for documentation improvement.
The documentation team will run the BZ through a proper team triage and will inform about the progress on the implementation of your feedback in this ticket.
Thank you!
Comment 2 Aldrey Souza 2024-01-31 14:59:38 UTC 
Hello Team,

 Following all steps from the documentation: 
 - 5.3. Using Active Directory
  https://access.redhat.com/documentation/en-us/red_hat_satellite/6.14/html-single/installing_satellite_server_in_a_connected_network_environment/index#Using_Active_Directory_satellite

 I see some issues:
 1) 5.3.2. Enrolling Satellite Server with the AD Server

   Performing the procedures, I got the error below when trying to join in AD server:
   ~~~
   [root@satellite ~]# realm join -v ADTEST.LAB --membership-software=samba -U ADUser01
    * Resolving: _ldap._tcp.adtest.lab
    * Performing LDAP DSE lookup on: 10.0.0.2
    * Performing LDAP DSE lookup on: ...
    * Successfully discovered: adtest.lab
   Password for ADUser01: 
    * Couldn't find file: /usr/sbin/oddjobd
    * Required files: /usr/sbin/oddjobd, /usr/libexec/oddjob/mkhomedir, /usr/sbin/sssd, /usr/bin/net
    * Resolving required packages
    ! PackageKit not available: The name org.freedesktop.PackageKit was not provided by any .service files
    ! Necessary packages are not installed: oddjob oddjob-mkhomedir sssd samba-common-tools
   realm: Couldn't join realm: Necessary packages are not installed: oddjob oddjob-mkhomedir sssd samba-common-tools
   Please check
       https://red.ht/support_rhel_ad 
   to get help for common issues.
   [root@satellite ~]# rpm -q sssd
   sssd-2.9.1-4.el8_9.x86_64
   [root@satellite ~]# rpm -q samba-common-tools
   samba-common-tools-4.18.6-2.el8_9.x86_64
   ~~~

   Then, the step '1. Install the required packages:' should be:
   ~~~
   # satellite-maintain packages install adcli ipa-python-compat krb5-workstation oddjob oddjob-mkhomedir realmd samba-common-tools sssd
   ~~~

 2) 5.3.3. Configuring Direct AD Integration with GSS-Proxy

   Performing the Verification steps, I can see the results below:
   ~~~
   [root@satellite ~]# kinit ADUser01
   Password for ADUser01: 
   [root@satellite ~]# klist
   Ticket cache: KCM:0
   Default principal: ADUser01

   Valid starting       Expires              Service principal
   01/30/2024 17:09:40  01/31/2024 03:09:40  krbtgt/ADTEST.LAB
	renew until 02/06/2024 17:09:31
   [root@satellite ~]# curl -k -u : --negotiate https://${HOSTNAME}/users/extlogin
   <html><meta http-equiv="refresh" content="0; URL=/users/login"><body>Kerberos authentication did not pass.</body></html>
   ~~~

   Looking at the log '/var/log/httpd/foreman-ssl_error_ssl.log', I see the error below:
   ~~~
   [Tue Jan 30 17:09:58.415060 2024] [authnz_pam:warn] [pid 73533:tid 139695403284224] [client 10.0.0.5:40748] PAM account validation failed for user aduser01: Permission denied
   [Tue Jan 30 17:09:58.415655 2024] [authz_core:error] [pid 73533:tid 139695403284224] [client 10.0.0.5:40748] AH01631: user aduser01: authorization failure for "/users/extlogin": 
   ~~~

   After some tests, I see this happens because we need to add in sssd configuration (/etc/sssd/sshd.conf):
   ~~~ config file: /etc/sssd/sshd.conf
   [domain/adtest.lab]
   ...
   ad_gpo_map_service = +foreman
   ~~~

   To reload the new configuration, I needed to perform:
   ~~~
   systemctl restart sssd
   ~~~

   After that, I was able to connect with success:
   ~~~
   [root@satellite ~]# curl -k -u : --negotiate https://${HOSTNAME}/users/extlogin
   <html><body>You are being <a href="https://satellite.adtest.lab/hosts">redirected</a>.</body></html>
   ~~~

   But seeing via ausearch command, I see the messages below:
   ~~~ command: ausearch -i | grep gssproxy
   type=PROCTITLE msg=audit(01/30/2024 17:09:58.308:1702) : proctitle=/usr/sbin/gssproxy -D 
   type=SYSCALL msg=audit(01/30/2024 17:09:58.308:1702) : arch=x86_64 syscall=openat success=no exit=EACCES(Permission denied) a0=AT_FDCWD a1=0x7f23f8006910 a2=O_RDONLY a3=0x0 items=0 ppid=1 pid=73468 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=gssproxy exe=/usr/sbin/gssproxy subj=system_u:system_r:gssproxy_t:s0 key=(null) 
   type=AVC msg=audit(01/30/2024 17:09:58.308:1702) : avc:  denied  { search } for  pid=73468 comm=gssproxy name=httpd dev="dm-0" ino=201881993 scontext=system_u:system_r:gssproxy_t:s0 tcontext=system_u:object_r:httpd_config_t:s0 tclass=dir permissive=0 
   type=PROCTITLE msg=audit(01/30/2024 17:09:58.329:1703) : proctitle=/usr/sbin/gssproxy -D 
   type=SYSCALL msg=audit(01/30/2024 17:09:58.329:1703) : arch=x86_64 syscall=openat success=no exit=EACCES(Permission denied) a0=AT_FDCWD a1=0x7f23f8007860 a2=O_RDONLY a3=0x0 items=0 ppid=1 pid=73468 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=gssproxy exe=/usr/sbin/gssproxy subj=system_u:system_r:gssproxy_t:s0 key=(null) 
   type=AVC msg=audit(01/30/2024 17:09:58.329:1703) : avc:  denied  { search } for  pid=73468 comm=gssproxy name=httpd dev="dm-0" ino=201881993 scontext=system_u:system_r:gssproxy_t:s0 tcontext=system_u:object_r:httpd_config_t:s0 tclass=dir permissive=0 
   ~~~

   To fix that, I performed the commands below to set the correct selinux context to 'krb5_keytab_t':
   ~~~
   # semanage fcontext -a -s system_u -t krb5_keytab_t '/etc/httpd/conf/http\.keytab'
   # restorecon -Rv /etc/httpd/conf/http.keytab
   ~~~

   If we add the semanage before creating the file 'http.keytab', we can set the correct selinux context:
   ~~~ step 6. Create a keytab entry:
   # semanage fcontext -a -s system_u -t krb5_keytab_t '/etc/httpd/conf/http\.keytab'
   # KRB5_KTNAME=FILE:/etc/httpd/conf/http.keytab net ads keytab add HTTP -U administrator -d3 -s /etc/net-keytab.conf
   # chown root.apache /etc/httpd/conf/http.keytab
   # chmod 640 /etc/httpd/conf/http.keytab
   ~~~

Regards,
Aldrey Souza
Comment 3 Adam Lazik 2024-01-31 16:45:17 UTC 
Hello!
Thank you both for the input. Currently working on fixing the procedure.
Comment 4 Aldrey Souza 2024-01-31 19:39:19 UTC 
Hello Team,

 Just fixing myself instead of 'sshd.conf' read 'sssd.conf':
 ===
   After some tests, I see this happens because we need to add in sssd configuration (/etc/sssd/sssd.conf):
   ~~~ config file: /etc/sssd/sssd.conf
   [domain/adtest.lab]
   ...
   ad_gpo_map_service = +foreman
   ~~~
 ===

Regards,
Aldrey Souza
Comment 5 Adam Lazik 2024-02-01 17:08:32 UTC 
I have created a draft of the new procedure: https://github.com/theforeman/foreman-documentation/pull/2737
There are some things which are not yet clear to me and I have asked my colleagues for SME review, so you can expect the draft to change.
Comment 7 Eric Helms 2024-06-06 17:00:43 UTC 
This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "SAT-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.