theforeman
Review adding AD as an external authentication source
According to https://issues.redhat.com/browse/SAT-22855, the procedure for direct AD integration with GSS-proxy needs updating. This PR continues the effort from https://github.com/theforeman/foreman-documentation/pull/2737.
Additionally, https://issues.redhat.com/browse/SAT-26355 requests adding two oddjob* packages to the same assembly.
- [x] I am okay with my commits getting squashed when you merge this PR.
- [x] I am familiar with the contributing guidelines.
Please cherry-pick my commits into:
- [x] Foreman 3.11/Katello 4.13
- [x] Foreman 3.10/Katello 4.12
- [x] Foreman 3.9/Katello 4.11 (Satellite 6.15; orcharhino 6.8/6.9)
- [x] Foreman 3.8/Katello 4.10
- [x] Foreman 3.7/Katello 4.9 (Satellite 6.14)
- [x] Foreman 3.6/Katello 4.8
- [x] Foreman 3.5/Katello 4.7 (Satellite 6.13; orcharhino 6.6/6.7)
- We do not accept PRs for Foreman older than 3.5.
The PR preview for 503934f6e775547484eb0700d5260b69cec6c7a3 is available at theforeman-foreman-documentation-preview-pr-3149.surge.sh
The following output files are affected by this PR:
- Installing_Server/index-foreman-deb.html
- Installing_Server/index-foreman-el.html
- Installing_Server/index-katello.html
- Installing_Server/index-orcharhino.html
- Installing_Server/index-satellite.html
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
I've commented on some issues based on my memory and I will proceed with testing this actual workflow documented, verbatim, without changes I've suggested.
I believe I have resolved all comments you've posted so far @lhellebr Let me know what else needs changing. Thanks!
Tested with the latest version and when running the installer, I get the following error.
2024-07-24 12:18:57 [NOTICE] [configure] System configuration has finished.
Error 1: Puppet Exec resource 'ipa-getkeytab' failed. Logs:
/Stage[main]/Foreman::Config/Exec[ipa-getkeytab]/before
before to File[/etc/httpd/conf/http.keytab]
/Stage[main]/Foreman::Config/Exec[ipa-getkeytab]
Starting to evaluate the resource (273 of 1654)
Failed to call refresh: '/bin/echo Get keytab && KRB5CCNAME=KEYRING:session:get-http-service-keytab kinit -k && KRB5CCNAME=KEYRING:session:get-http-service-keytab /usr/sbin/ipa-getkeytab -k /etc/httpd/conf/http.keytab -p HTTP/<FQDN> && kdestroy -c KEYRING:session:get-http-service-keytab' returned 1 instead of one of [0]
'/bin/echo Get keytab && KRB5CCNAME=KEYRING:session:get-http-service-keytab kinit -k && KRB5CCNAME=KEYRING:session:get-http-service-keytab /usr/sbin/ipa-getkeytab -k /etc/httpd/conf/http.keytab -p HTTP/<FQDN> && kdestroy -c KEYRING:session:get-http-service-keytab' returned 1 instead of one of [0]
Evaluated in 0.04 seconds
/Stage[main]/Foreman::Config/Exec[ipa-getkeytab]/creates
Checking that 'creates' path '/etc/httpd/conf/http.keytab' exists
Checking that 'creates' path '/etc/httpd/conf/http.keytab' exists
Exec[ipa-getkeytab](provider=posix)
Executing '/bin/echo Get keytab && KRB5CCNAME=KEYRING:session:get-http-service-keytab kinit -k && KRB5CCNAME=KEYRING:session:get-http-service-keytab /usr/sbin/ipa-getkeytab -k /etc/httpd/conf/http.keytab -p HTTP/<FQDN> && kdestroy -c KEYRING:session:get-http-service-keytab'
Executing '/bin/echo Get keytab && KRB5CCNAME=KEYRING:session:get-http-service-keytab kinit -k && KRB5CCNAME=KEYRING:session:get-http-service-keytab /usr/sbin/ipa-getkeytab -k /etc/httpd/conf/http.keytab -p HTTP/<FQDN> && kdestroy -c KEYRING:session:get-http-service-keytab'
/Stage[main]/Foreman::Config/Exec[ipa-getkeytab]/returns
Get keytab
kinit: Cannot determine realm for host (principal host/<FQDN>@)
change from 'notrun' to ['0'] failed: '/bin/echo Get keytab && KRB5CCNAME=KEYRING:session:get-http-service-keytab kinit -k && KRB5CCNAME=KEYRING:session:get-http-service-keytab /usr/sbin/ipa-getkeytab -k /etc/httpd/conf/http.keytab -p HTTP/<FQDN> && kdestroy -c KEYRING:session:get-http-service-keytab' returned 1 instead of one of [0]
Get keytab
kinit: Cannot determine realm for host (principal host/<FQDN>@)
1 error was detected during installation.
Please address the errors and re-run the installer to ensure the system is properly configured.
Failing to do so is likely to result in broken functionality.
Note that the realm (In this log, <FQDN> is doctored to make it public) is derived from the host's FQDN which is different to the realm. Normally, the realm is taken from the config files created as per docs but here, the installer doesn't use it.
My hypothesis is it's because the installer expects the keytab to be in a certain place (that changed) but I can't confirm it yet.
Additionally, in part 5.8.3 step 8a, it's unclear which section of the file the text should be added to.
My hypothesis is it's because the installer expects the keytab to be in a certain place (that changed) but I can't confirm it yet.
I don't think I can help with that but let me know if I'm missing something and there is anything I'm expected to do about this.
Additionally, in part 5.8.3 step 8a, it's unclear which section of the file the text should be added to.
I clarified that the lines go to the domain section for the AD domain. And I also added a reference to the sssd-ad man page (there are multiple man pages related to sssd.conf so it might be helpful to point users to the most relevant one).
My hypothesis is it's because the installer expects the keytab to be in a certain place (that changed) but I can't confirm it yet.
I don't think I can help with that but let me know if I'm missing something and there is anything I'm expected to do about this.
It means what we agreed to do here https://github.com/theforeman/foreman-documentation/pull/3149#discussion_r1688115759 and what was suggested in the ticket was kinda illegal. Not by the nature of the change, after all, we followed the KB... but it seems the satellite EXPECTS the keytab to be in /etc/httpd/conf/http.keytab. It can be fixed either by:
- Devels changing this expectation. This would be justifiable but IMO not necessary. CC @adamruzicka
- You just changing it back to the original path. Effectively negating what is perhaps the main point of the whole ticket - but solving the same problem in a different manner.
Anyway, this must be fixed, it's a blocker, the process doesn't work as is.
When exactly following the docs in this PR's current state but changing /etc/gssapi/http.conf to /etc/httpd/conf/http.keytab, I got a working configuration.
but solving the same problem in a different manner.
So if we kept the old path (/etc/httpd/conf/http.keytab), then this would reduce the changes here to:
- setting a different selinux label on it
- setting a different user group on it
If this is enough to resolve the issue then I'd prefer it over changing the puppet modules to expect the keytab to be in a different place, especially if we want to have this done soon.
If this is enough to resolve the issue then I'd prefer it over changing the puppet modules to expect the keytab to be in a different place, especially if we want to have this done soon.
You can use --foreman-http-keytab /path/to/keytab. It just defaults to ${apache::conf_dir}/http.keytab.
I'm not sure about the SELinux policy, because that comes from the base SELinux policy. Looks like the default is /etc/httpd/conf/keytab which we never used.
# semanage fcontext -l | grep keytab
/etc/httpd/conf/keytab regular file system_u:object_r:httpd_keytab_t:s0
/etc/krb5\.keytab all files system_u:object_r:krb5_keytab_t:s0
/etc/krb5kdc/kadm5\.keytab regular file system_u:object_r:krb5_keytab_t:s0
/var/kerberos/krb5(/.*)? all files system_u:object_r:krb5_keytab_t:s0
/var/kerberos/krb5kdc/kadm5\.keytab regular file system_u:object_r:krb5_keytab_t:s0
Looking at the procedure it states The Apache user must not have access to the keytab file. so then it is indeed very illogical to use the Apache config directory.
If possible, I'd like to limit this PR to addressing https://issues.redhat.com/browse/SAT-22855 in a way that enables us to close that ticket. That would involve:
- Reviewing the keytab's location and permissions (ongoing conversation)
- A decision on whether to include a step for SPN in AD (resolved)
- Adding oddjob* packages (resolved)
The last time I tried to look at the whole AD/SSSD integration procedure from a bigger perspective, it resulted in https://github.com/theforeman/foreman-documentation/pull/3056 which became unmanageable and I had to close it. Because it's absolutely true that there are larger issues to deal with. Can we track them in https://issues.redhat.com/browse/SAT-26039 in order to avoid blocking this PR?
I will retest once you decide and put it in the PR but until then, I don't have any more input. Do you need anything from me now?
@asteflova you mentioned that it's more common to deploy IPA and then link your IPA and AD installations. I think it's worth considering making that the recommended AD integration strategy from an authentication perspective. That means we could replace the whole procedure with a description of the strategy and links to the IPA-authentication guide and appropriate IPA/IDM documentation.
There was a discussion about that and it may happen in the future, not in this PR though. Also note that scenario is not currently tested or automated.
@asteflova you mentioned that it's more common to deploy IPA and then link your IPA and AD installations.
I'm afraid I didn't explain myself correctly at the meeting. Connecting directly to AD (without using IPA) is a valid use case. For example, you want direct integration if you are only connecting a small number of systems to AD.
It's okay that 5.10. Configuring Active Directory as an external identity provider for Foreman (link to nightly) wants to document it. The highly suspicious thing I mentioned at the meeting is that 5.10.5. Configuring the FreeIPA server to use cross-forest trust (nightly) talks about configuring an IPA server as part of that use case. If your goal is direct integration (without IPA), then you shouldn't need to use IPA (but 5.10.5. asks you to do just that).
Per the RHEL Windows integration guide:
- 6.1. Direct integration of Linux systems into Active Directory: "In direct integration, Linux systems are connected directly to Active Directory (AD)."
Compare that to:
- 6.2. Indirect integration of Linux systems into Active Directory by using Identity Management: "In indirect integration, Linux systems are first connected to a central server which is then connected to Active Directory (AD)." That central server is IPA.
The highly suspicious thing I mentioned at the meeting is that 5.10.5. Configuring the FreeIPA server to use cross-forest trust (nightly) talks about configuring an IPA server as part of that use case.
... and I think I've just realized why the procedure is there. Spoiler alert: It's kind of my fault and I'll send a PR to fix it soon.
... and I think I've just realized why the procedure is there. Spoiler alert: It's kind of my fault and I'll send a PR to fix it soon.
Well it's a good thing that there are other things wrong with the procedures too! (I'd feel pretty awkward if there weren't.)
I'll split out the non-controversial parts of this PR into other PRs to get those merged at least. For the trickier parts concerning the whole feature, let's discuss them with Endeavour and Platform first to try to figure out a solution.
@ekohl @lhellebr I looked into dropping the GSS proxy parts of the user story (5.8. Configuring Active Directory as an external identity provider for Satellite) and didn't find a way to do that. The GSS proxy parts seem intertwined with the rest too much.
As an alternative, I propose to merge the following changes. These are the only changes requested in https://issues.redhat.com/browse/SAT-22855 that I think we are able to implement now and Lukáš got it working this way:
- The keytab is stored back in its original location (/etc/httpd/conf/htt.keytab)
- SELinux context is applied to the keytab file, ownership set to root.root and permissions to 600
- oddjob* packages added
As a reminder, this is only temporary. I absolutely want to get to the bottom of this but it will take some time, a cross-team effort, and a lot of ice cream. In the meantime, we can at least get this partial fix merged for now. What do you think?
As I tried to explain, the use of gssproxy and
{foreman-installer} --foreman-ipa-authentication=truedoes not make sense in the current implementation. Fundamentally, the installer will enforce that Apache can read the keytab and the whole purpose of gssproxy is to ensure Apache can't read the keytab and still work.This is why I suggested to simplify the whole procedure to drop gssproxy. We can backport that to existing support versions. Then in the next version (timing wise, probably Foreman 3.13) we can implement support for gssproxy.
I heard you and I did try dropping the GSS proxy elements of the current procedures. I've updated this PR to show what I ended up with: a procedure that misses several steps and no way to test it. I didn't feel confident enough to go in that direction.
On the other hand, the alternative was to keep the GSS proxy parts included even though the whole configuration doesn't exactly do what GSS proxy promises to be. This was confirmed to result in a working setup: https://github.com/theforeman/foreman-documentation/pull/3149#issuecomment-2249893886 which is why it seemed like a better choice to me.
A third alternative could be to just close this PR, focus on finding a proper way to configure direct AD integration, and accept that we won't try to find an interim solution (which is what this PR has turned into). This would be my preference. What are your thoughts @ekohl?
Rebased and split off two changes into separate PRs: https://github.com/theforeman/foreman-documentation/pull/3189 and https://github.com/theforeman/foreman-documentation/pull/3190
Switching back to draft because this is nowhere near ready for merging. Also, updating the PR title to reflect the change of scope. My plan is to get my hands on an AD machine and try to connect a Foreman server to the AD realm by following the RHEL docs, more specifically using the SSSD-based procedure because that’s the recommended one.
The assumption I’m making is that we should be able to treat the Foreman server base system as any other RHEL machine for the actual join (thus following the standard procedure documented on the RHEL side) and then run additional steps, like --foreman-ipa-authentication=true, on top of that. That would be preferable to the current situation where we are basically providing our own version of the AD join procedure.
Once we have a basic procedure like that in place, we will be in a better position to think about bringing the GSS Proxy keytab separation into the picture.
After talking to an SSSD engineer, I've determined the bare minimum that should result in the Foreman server recognizing AD as an authentication source. Emphasis on "should".
However, approaching the procedure like this -- referencing RHEL docs as much as possible -- would help us out of the current situation where on the Foreman side, we are basically documenting our own way of joining an AD domain that diverges from what the SSSD team actually recommends and maintains.
I still don't have an environment to test the workflow but I'm getting closer to obtaining one.
Thanks to @adamruzicka, we now have a working procedure to join a Foreman server directly to an AD domain and configure the AD server as an external authentication source.
I'm marking the procedure as ready for review to open it up for comments, but I will also reach out to a couple of people for more detailed review regarding esp. QE testing and Samba.
I also updated the PR description in case any potential reviewers need a recap.
As far as tech review goes: The current status is that we confirmed that this procedure works as written, but I want more input from QE. That's why I'm adding the tech review needed label but anyone else is welcome to poke holes in it too.
One thing I did not need to realize on a Friday afternoon is that the new steps do not configure Kerberos SSO for AD users.
# kinit ad_user
# curl -k -u : --negotiate https://foreman.example.com/users/extlogin
# <html><meta http-equiv="refresh" content="0; URL=/users/login"><body>Kerberos authentication did not pass.</body></html>
We will need to figure out what steps need to be taken to configure SSO, but perhaps a subsequent PR will do.
I moved the SSSD-only procedure to https://github.com/theforeman/foreman-documentation/pull/3286 where I want to continue exploring that path. I tried using a different utility to generate the keytab (the currently documented one relies on Samba) but didn't succeed. I can't afford to block fixing this procedure with this, so with this PR, I'm returning to the SSSD+Samba-based solution. This is also known as reinventing the wheel or, as I prefer to call it, a 'valuable learning opportunity'. I also updated this PR's description.
@mmuehlfeldRH: I addressed your suggestions and resolved the related comment threads.
@maximiliankolb: I addressed the one breaking change you found (installing packages) and resolved the other comments.
@ekohl: I believe I addressed your request for changes as well by dropping the steps related to privilege separation for Apache and verifying that the remaining steps work.