Computer Accounts in simple_allow_groups

[Yehuda Katz]

We are using SSSD to connect RHEL systems to Microsoft Active Directory.
Access is granted to groups using the `simple_allow_groups` option and those groups are also used to allow sudo access.
Some of these groups have members that are the computer accounts for other computers in the domain.

Should that be considered a security risk? For example, could someone with root access on one system recover the computer account information and use that computer account to log in to a different system?

[Spike White]

(I was going to let those more in-depth knowledgeable in sssd answer this,
but I'm not seeing any such answers.)

This will not bo a problem -- for multiple reasons.

The first is that when searching AD for a specified user name,  sssd is
searching for a "user" object.  A computer object is not a user object.

You can verify this for yourself by doing a 'getent -s sss group
<AD_group>'.  It will list only user objects under that group and often
only some of these (see below).

Secondly, where sssd finds an AD user objects depends additionally on what
type of LDAP user mapping you're doing.  For instance, we do RFC2307bis AD
schema extension, where we have to specify additional LDAP attributes for
an account.  Attributes like the UID, primary GID, login shell, gecos, home
directory.

Without those additional attributes set on a user object, sssd will not
report the user object.  So in the 'getent -s sss group <AD group>' above,
sssd will report only the members that are user objects and have those
additional LDAP attributes filled in.

Spike White

On Thu, Jul 3, 2025 at 5:45 PM Yehuda Katz via sssd-users <
[e-mail]> wrote:
> We are using SSSD to connect RHEL systems to Microsoft Active Directory.
> Access is granted to groups using the `simple_allow_groups` option and
> those groups are also used to allow sudo access.
> Some of these groups have members that are the computer accounts for other
> computers in the domain.
>
> Should that be considered a security risk? For example, could someone with
> root access on one system recover the computer account information and use
> that computer account to log in to a different system?
> --
> _______________________________________________
> sssd-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail].o...
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

[Sumit Bose]

Am Sat, Jul 05, 2025 at 10:12:45PM -0500 schrieb Spike White via sssd-users:
> (I was going to let those more in-depth knowledgeable in sssd answer this,
> but I'm not seeing any such answers.)

Hi,

I typically wait a bit hoping that community members share their
knowledge and experience first to get a broader discussion :-)
> This will not bo a problem -- for multiple reasons.
>
> The first is that when searching AD for a specified user name,  sssd is
> searching for a "user" object.  A computer object is not a user object.

Unfortunately AD thinks it is and adds the 'user' and 'person'
objectclasses to a computer object.
> You can verify this for yourself by doing a 'getent -s sss group
> <AD_group>'.  It will list only user objects under that group and often
> only some of these (see below).
>
> Secondly, where sssd finds an AD user objects depends additionally on what
> type of LDAP user mapping you're doing.  For instance, we do RFC2307bis AD
> schema extension, where we have to specify additional LDAP attributes for
> an account.  Attributes like the UID, primary GID, login shell, gecos, home
> directory.

You are right that without POSIX id-mapping (ldap_id_mapping = False)
you have to set the UID and GID attributes in AD and as long as the
computer objects do not have those attributes set they will not be
available on the client system.

But with enabled POSIX id-mapping (default for id_provider=ad) computer
object will get a POSIX UID and a primary GID assigned automatically and

getent passwd 'COMPUTERNAME$@AD.DOMAIN'

will return the "user" entry of the computer and it will be present as a
member in every group it is a member of in AD.

But you can avoid this with the help of the 'ldap_user_search_base'
option. As long as user and computer objects are in different OUs, e.g.
like by default cn=User and cn=Computers you can set the search base so
that only the OUs of the users are searched. If you have OUs where user
and computer objects are mixed you can use the filter component of the
'ldap_user_search_base' option like e.g.

ldap_user_search_base = dc=ad,dc=domain?subtree?(!(objectclass=computer))

to filter out the computer objects. In both cases you should set

ldap_ignore_unreadable_references = True

to tell SSSD to not treat unresolvable members as an error.
> Without those additional attributes set on a user object, sssd will not
> report the user object.  So in the 'getent -s sss group <AD group>' above,
> sssd will report only the members that are user objects and have those
> additional LDAP attributes filled in.
>
> Spike White
>
> On Thu, Jul 3, 2025 at 5:45 PM Yehuda Katz via sssd-users <
> [e-mail]> wrote:
> > We are using SSSD to connect RHEL systems to Microsoft Active Directory.
> > Access is granted to groups using the `simple_allow_groups` option and
> > those groups are also used to allow sudo access.
> > Some of these groups have members that are the computer accounts for other
> > computers in the domain.
> >
> > Should that be considered a security risk? For example, could someone with
> > root access on one system recover the computer account information and use
> > that computer account to log in to a different system?

Yes, if you are root you can get a Kerberos TGT  with the help of the
keytab with the machine account credentials and if ssh is configured to
support GSSAPI-Authentication you can log into other computers with the
machine account (but not as root). However, if the attacker is already
root you have to be aware there will be most probably also other ways to
attack your network.

HTH

bye,
Sumit
> > --
> > _______________________________________________
> > sssd-users mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > 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/[e-mail].o...
> > Do not reply to spam, report it:
> > https://pagure.io/fedora-infrastructure/new_issue
> -- 
> _______________________________________________
> sssd-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail].o...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue