On Wed, Mar 29, 2023 at 5:01 PM Pieter Voet <pieterv...@nl.ibm.com> wrote:
> So, that should be it... I now have to get to the Active Directory > department on my corporate environment and ask them to set the flag > for me, because it seems that only Administrator can set the flag ( > if not customized ), even if you ( a non-Administrator account owns > the machine account...). My understanding (which could be incorrect, as I am not a Windows admin) is that this is exactly the point. The ability to join hosts to the domain is often delegated fairly loosely. For example, in our organization, various groups have the ability to join hosts into specific OUs. Therefore, just because a random host is joined to the domain doesn’t necessarily mean that it should be trusted to receive delegated credentials. By creating a separate flag to indicate whether a host can be trusted to receive delegated credentials, and then permitting domain admins to specify who can set that flag on what OUs, this permits differentiating hosts that are simply joined to the domain versus hosts that are joined to the domain and operated by admins who can be trusted not to exfiltrate credentials delegated to their hosts. Of course, for our environment, this backfired horribly, as we use NFSv4 home directories with sec=krb5p everywhere, which means that for a remote login, you must either delegate a credential or use keyboard-interactive authentication in order to acquire a new credential. When PuTTY was configured to use GSSAPI authentication, users wouldn’t have access to their NFS home directory after logging into a Linux host, because PuTTY would refuse to delegate the credential necessary to access it. Until we finally figured out that the target host needed to have the TRUSTED_FOR_DELEGATION flag in order for PuTTY to delegate the damn credential, our work-around was to tell Windows users to disable GSSAPI authentication and just use password authentication (plus Duo MFA) whenever they needed to ssh into a Linux host. So, effectively, in order to avoid giving a (potential, hypothetical) rogue admin a delegated credential, we were forced to give that same rogue admin… the actual user’s password. Whee. _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org 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/sssd-users@lists.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
