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> 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]>:

   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

Reply via email to