Controlling SSH access by AD group in Domain B, with users from Domain A (One Way Forest Trust Domain B -> Domain A)

[matam44]

Hi all,

wondering if you can help with something we are attempting to setup.

We are attempting to control SSH access to our linux (Red Hat 9.4) servers by an AD security group in Domain B with users from Domain A added to the Domain B group. Domain B is a resource AD environment where our servers reside and our users are in Domain A. We have in place a "One-Way Forest Trust" from Domain B to Domain A ("Users in Domain A can access resources in Domain B").

We have tried a couple of different solutions:

Solution 1:
We have tried realm join (sssd) to Domain B only, but we were unable to natively see the trusted domains using the command "sssctl domain-list -v". Therefore, we are unable to find ("id") users in the trusted domain Domain A

NOTE: This does work with an AD "External Trust", but not a "Forest Trust"

Solution 2:
We have tried the solution on this page: https://access.redhat.com/solutions/4035171

We are able to join our linux servers to both domains as specified in the document. We can "id" users in both domains, but cannot see group membership (getent group ; id -a [email protected]) for a user in Domain A which is a member of a group in Domain B

Any advice would be appreciated. Have also reached out to Red Hat Support, but thought I'd ask in this forum also.

Thanks in advance.

[sumit-bose]

Hi,

Solution 2 does not work because SSSD considers each of the configured domains as individual entities without any connections and hence cross-domain memberships are not possible. This is by design and will most probably not change.

Solution 1 does not work because SSSD currently does not follow forest trusts but only trusts in a single forest and to some extend external trusts. If an external trust is working for you I would recommend to use this for the time being.

HTH

bye,
Sumit

[matam44]

Thankyou @sumit-bose for your response. What you have written confirms exactly what we have found.

Seems like the only possibility to use sssd in our scenario is to have the External Trust in place and use Solution 1. In our testing testing of this scenario, we had some inconsistent results with group memberships (again, agrees with what you mentioned above).

Unfortunately for us, the forest trust is already in place and unlikely to be changed, so it would appear SSSD can't be used to achieve what we want.

Red Hat support have pointed us at Winbind. That has not worked for us also.

For most of the solutions posted, we are able to get to a point where we can "id" users in both domains and get details about the users' groups in their OWN domain. Therefore we can have the users authenticate and login to the linux servers using SSH.

It just doesn't seem to work when the user a user in Domain A is a member of a group in Domain B. Controlling access via the group in Domain B doesn't not seem to work for users authenticating in from Domain A.... because we can't see these details when doing an "id" of the user in Domain A. Same goes for "getent group" of the group in Domain B.

[sumit-bose]

Hi,

as you have already analyzed SSSD is currently not able to help in this environment.

I cannot comment much about winbind but please note that here the id command will only display all the group-memberships of a user after the user has logged into the system. The reason is that winbind is using AD APIs which require a user login to get all the user details including the memberships.

What would be interesting to know is what AD itself thinks about the group memberships of the user on the given client. Here the PAC from a Kerberos ticket is always a good source. If you follow the steps from https://www.freeipa.org/page/Howto/Inspecting_the_PAC#ad-client you should get a dump of the whole PAC content where groups are listed with their SID.

HTH

bye,
Sumit