Thank you Sam, that was quite helpful! Am Mo., 31. Juli 2023 um 12:38 Uhr schrieb Sam Morris <[email protected]>:
> Not an AD expert so perhaps someone else can speak up if I'm getting > anything wrong... > > AD doesn't have a first class object for representing services. Kerberos > principals are either associated with a computer account or a user account. > > It's my understanding that all the Kerberos keys for the SPNs on an > account are equivalent, i.e., they all let you authenticate as the computer > account. So even if you separate out the keys into separate keytab files > per-service, they can all authenticate to AD as the same computer account. > > AD's solution to this was introduced with Windows Server 2008 R2 in the > form of "managed service accounts". This is where AD manages a > service-specific user account and its Kerberos keys, rotating them every 30 > days. The account is linked to a computer account which is able to retrieve > the account's credentials* and, e.g., put them into a keytab for another > process to use. If the managed service account's key is compromised then > the attacker can't authenticate as the computer, only the separated service > account. > > (* Not terribly sure about this as the technical documentation is so > scant, but I see references to a "Key Distribution Service" (KDS) which > implies that the computer account is retrieving the MSA's keys from AD > domain controllers. But it's possible that the KDS is only used for the > enhanced "group managed service accounts" facility introduced later on, > which lets a managed service account be linked to a security group of > computers, all of which can retrieve the managed service acount credentials. > ) > > Whether SSSD is able to make use of this this, I don't know. There are > some docs at > <https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/integrating_rhel_systems_directly_with_windows_active_directory/assembly_accessing-ad-with-a-managed-service-account_integrating-rhel-systems-directly-with-active-directory> > <https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/integrating_rhel_systems_directly_with_windows_active_directory/assembly_accessing-ad-with-a-managed-service-account_integrating-rhel-systems-directly-with-active-directory> > but they're written from the perspective of a host that hasn't been joined > to the domain with 'realm join'. If the host has been joined then I don't > know how you'd go about configuring SSSD to retrieve the credentials and > store them in a separate keytab file. > > Sam > > 25 Jul 2023 15:08:36 Stefan Bauer <[email protected]> > <[email protected]>: > > Spike, > > thank you again. I'm aware of the link James supplied and i already tested > it successfully. As I'm doing some research, i just wanted to have a > second/third opinion on how other admins handle the keytab/rotation > problem. > Specifically if it is bad practice to have many SPNs on a single > host-object in Active-Directory :) > > So it looks like i either have to create unique host/user/objects in AD > and use individual keytab-files for each service, or do the separation in > software with gssproxy. > > Stefan > > Am Di., 25. Juli 2023 um 15:54 Uhr schrieb Spike White < > [email protected]>: > >> Stefan, >> >> From what I'm reading, it looks like James supplied the answer. >> gssproxy. This URL: >> gssproxy/docs/Apache.md at main · gssapi/gssproxy · GitHub >> <https://github.com/gssapi/gssproxy/blob/main/docs/Apache.md> >> >> seems to demonstrate how to implement this for Apache webserver. >> >> Spike >> >> On Tue, Jul 25, 2023 at 12:50 AM Stefan Bauer <[email protected]> wrote: >> >>> Thank you Spike and James for your reply. That was quite helpful. >>> Yes i currently do have a single host principal in Active-Directory, >>> that has numerous servicePrincipalNames: >>> HOST/... >>> HTTP/ >>> SQL/... >>> >>> for al services, running on this specific host. >>> >>> So it can not be separated as the only credential for that host is the >>> machine account itself. Correct? >>> >>> Is it bad practice to have additional SPNs on the host principal? >>> >>> How do you associate and rotate your keytabs for services? >>> >>> Thank you. >>> >>> Stefan >>> >>> >>> >>> Am Mo., 24. Juli 2023 um 23:14 Uhr schrieb Spike White < >>> [email protected]>: >>> >>>> I know on a former commercial product I used the monthly machine >>>> account credential renewal had a "hook" parameter where you could specify >>>> an executable script to be called. It was designed to work with Samba, so >>>> that you could write the samba keytab file without Samba needing to access >>>> the /etc/krb5.keytab file. >>>> >>>> Possibly sssd has such a post-rotate hook parameter as well. >>>> >>>> That worked great for creating a Samba-viewable credentials. >>>> >>>> However, it sounds like you're defining SPNs as alternate names for the >>>> host principal. I don't see how you could write a HTTP.keytab file or so >>>> with entries for HTTP/<service>@<domain> without embedding the >>>> credentials for the host principal (under the HTTP/ SPN of course). >>>> >>>> Spike >>>> >>>> On Thu, Jul 20, 2023 at 7:38 AM Stefan Bauer <[email protected]> >>>> wrote: >>>> >>>>> Dear Users, >>>>> >>>>> i really love SSSD and also the auto-renewal of the host-keytab file. >>>>> >>>>> On many hosts we add the SPNs >>>>> >>>>> HTTP/ >>>>> SQL/... >>>>> >>>>> directly to the machine-account in Active-Directory. This is all fine >>>>> and works. >>>>> >>>>> However i have a bad feeling about letting services read the keytab >>>>> file as it gives access to the machine-account. >>>>> >>>>> Opinions? >>>>> >>>>> How do you handle service keytabs and it's rotation? >>>>> >>>>> Thank you. >>>>> >>>>> Stefan >>>>> _______________________________________________ >>>>> sssd-users mailing list -- [email protected] >>>>> To unsubscribe send an email to >>>>> [email protected] >>>>> Fedora Code of Conduct: >>>>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >>>>> List Guidelines: >>>>> https://fedoraproject.org/wiki/Mailing_list_guidelines >>>>> List Archives: >>>>> https://lists.fedorahosted.org/archives/list/[email protected] >>>>> Do not reply to spam, report it: >>>>> https://pagure.io/fedora-infrastructure/new_issue >>>>> >>>> _______________________________________________ >>>> sssd-users mailing list -- [email protected] >>>> To unsubscribe send an email to [email protected] >>>> Fedora Code of Conduct: >>>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >>>> List Archives: >>>> https://lists.fedorahosted.org/archives/list/[email protected] >>>> Do not reply to spam, report it: >>>> https://pagure.io/fedora-infrastructure/new_issue >>>> >>> _______________________________________________ >>> sssd-users mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> Fedora Code of Conduct: >>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >>> List Archives: >>> https://lists.fedorahosted.org/archives/list/[email protected] >>> Do not reply to spam, report it: >>> https://pagure.io/fedora-infrastructure/new_issue >>> >> _______________________________________________ >> sssd-users mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedorahosted.org/archives/list/[email protected] >> Do not reply to spam, report it: >> https://pagure.io/fedora-infrastructure/new_issue >> > _______________________________________________ > sssd-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/[email protected] > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue >
_______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
