hi,
we have a working one way trust between an AD forest and a RHEL 7 forest.
In order to use AD nested groups, do we need to add an external IDM group for every nested group?
-- Groeten, natxo
hi,
On Wed, Apr 22, 2020 at 7:26 PM Natxo Asenjo natxo.asenjo@gmail.com wrote:
In order to use AD nested groups, do we need to add an external IDM group for every nested group?
specifically, our AD people have global groups (account groups, they say)
with the user accounts, and the domain local groups (resource groups, they call them) have these global groups as members.
So, in order to grant the people on the domain local groups which have no direct user members, should we create both external groups in Idm? Both the global group and the domain local group? -- Groeten, natxo
On ke, 22 huhti 2020, Natxo Asenjo via FreeIPA-users wrote:
hi,
On Wed, Apr 22, 2020 at 7:26 PM Natxo Asenjo natxo.asenjo@gmail.com wrote:
In order to use AD nested groups, do we need to add an external IDM group for every nested group?
specifically, our AD people have global groups (account groups, they say)
with the user accounts, and the domain local groups (resource groups, they call them) have these global groups as members.
So, in order to grant the people on the domain local groups which have no direct user members, should we create both external groups in Idm? Both the global group and the domain local group?
Domain local groups are not visible through the forest trust, so they cannot be used in FreeIPA for access control means.
Global groups can be used if they are security groups and not just distribution groups.
On Thu, Apr 23, 2020 at 8:47 AM Alexander Bokovoy abokovoy@redhat.com wrote:
Domain local groups are not visible through the forest trust, so they cannot be used in FreeIPA for access control means.
Global groups can be used if they are security groups and not just distribution groups.
aha, thanks for this piece of information, I could not find it on the documentation (which is probably my entire fault ;-) ).
Is this the reason why? https://docs.microsoft.com/en-us/windows/win32/ad/group-objects
In that document, in the scope part:
group scope group can be assigned permission in ---------------- ------------------------------------------------- universal any domain or forest global Member permissions can be assigned in any domain domain local Member permissions can be assigned only within the same domain as the parent domain local group
Is this the technical reason the Idm trusting forest cannot see the domain local groups? So we require global or universal groups?
I need to justify some stuff to our AD people, that's why I ask ;-)
Thanks in advance. -- Groeten, natxo
On to, 23 huhti 2020, Natxo Asenjo via FreeIPA-users wrote:
On Thu, Apr 23, 2020 at 8:47 AM Alexander Bokovoy abokovoy@redhat.com wrote:
Domain local groups are not visible through the forest trust, so they cannot be used in FreeIPA for access control means.
Global groups can be used if they are security groups and not just distribution groups.
aha, thanks for this piece of information, I could not find it on the documentation (which is probably my entire fault ;-) ).
Is this the reason why? https://docs.microsoft.com/en-us/windows/win32/ad/group-objects
In that document, in the scope part:
group scope group can be assigned permission in
universal any domain or forest global Member permissions can be assigned in any domain domain local Member permissions can be assigned only within the same domain as the parent domain local group
Is this the technical reason the Idm trusting forest cannot see the domain local groups? So we require global or universal groups?
I need to justify some stuff to our AD people, that's why I ask ;-)
It is covered in Microsoft documentation for Active Directory protocols.
MS-AUTHSOD 1.1.1.4.1: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-authsod/5975... MS-KILE 3.3.5.7.3: https://docs.microsoft.com/en-us/openspecs/windows_protocols/MS-KILE/e55ad92... MS-PAC 4.1.2.1: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-pac/6dd1b247...
So *any* service ticket towards a service outside of the user's domain will not have domain local groups in the PAC record, when issued by AD DC. As a result, when SSSD on IPA client would be analyzing the PAC record from user's Kerberos ticket, it will not have any domain local groups mentioned there and they cannot be used to define access rights outside of the domain.
On Thu, 23 Apr 2020 at 12:45, Alexander Bokovoy abokovoy@redhat.com wrote:
On to, 23 huhti 2020, Natxo Asenjo via FreeIPA-users wrote:
On Thu, Apr 23, 2020 at 8:47 AM Alexander Bokovoy abokovoy@redhat.com wrote:
Domain local groups are not visible through the forest trust, so they cannot be used in FreeIPA for access control means.
Global groups can be used if they are security groups and not just distribution groups.
aha, thanks for this piece of information, I could not find it on the documentation (which is probably my entire fault ;-) ).
Is this the reason why? https://docs.microsoft.com/en-us/windows/win32/ad/group-objects
In that document, in the scope part:
group scope group can be assigned permission in
universal any domain or forest global Member permissions can
be
assigned in any domain domain local Member permissions can be assigned only within the same domain as the parent domain local group
Is this the technical reason the Idm trusting forest cannot see the domain local groups? So we require global or universal groups?
I need to justify some stuff to our AD people, that's why I ask ;-)
It is covered in Microsoft documentation for Active Directory protocols.
MS-AUTHSOD 1.1.1.4.1: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-authsod/5975... MS-KILE https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-authsod/597504d8-5408-4629-9d81-aab661e6c953MS-KILE 3.3.5.7.3: https://docs.microsoft.com/en-us/openspecs/windows_protocols/MS-KILE/e55ad92... MS-PAC https://docs.microsoft.com/en-us/openspecs/windows_protocols/MS-KILE/e55ad922-4940-432d-a253-41919d6efd24MS-PAC 4.1.2.1: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-pac/6dd1b247...
So *any* service ticket towards a service outside of the user's domain will not have domain local groups in the PAC record, when issued by AD DC. As a result, when SSSD on IPA client would be analyzing the PAC record from user's Kerberos ticket, it will not have any domain local groups mentioned there and they cannot be used to define access rights outside of the domain.
Awesome. Thanks for this explanation, it really helps
freeipa-users@lists.fedorahosted.org