MAN: Add note about AD Group types #6263
Conversation
justin-stephenson
force-pushed
the
ad_group_type_man_update
branch
from
fe284e7
to
4a23826
Compare
|
Thank you. Ack. |
|
Does this need another reviewer? |
|
Yes, we talked about it and assigned to Sumit in some previous meeting. |
| <para> | ||
| SSSD only resolves Security-enabled Active Directory group types. | ||
| (i.e. Not <quote>distribution</quote> groups) | ||
| </para> |
There was a problem hiding this comment.
Hi,
I think Security-enabled is not common Active Directory speak in this context. I would suggest something like SSSD only resolves Active Directory Security Groups (since Security Group is used in AD User and Computers in the user and group listing) or SSSD only resolves Active Directory groups of group type "Security"(since this is shown in the properties of a group). @abbra, do you agree or do you have other suggestions?
We already have a reference to MSFT documentation in the sssd-ad man page, so I think it might worth to add https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-groups here as well.
bye,
Sumit
There was a problem hiding this comment.
I'd prefer Security Groups but you need to add more details around 'Domain-Local' scope, I think. It becomes a bit complex to explain ;)
There was a problem hiding this comment.
Hi,
thanks, adding some info about how domain-local groups are handled is a good idea. @justin-stephenson, can you add it or do you need more context?
bye,
Sumit
There was a problem hiding this comment.
There is mention of how SSSD handles domain local groups in the option description for ad_allow_remote_domain_local_groups. Is it enough or should it be mentioned in this part as well?
There was a problem hiding this comment.
Hi,
I would copy the content into this part as well.
bye,
Sumit
There was a problem hiding this comment.
Updated, please check. Thank you.
justin-stephenson
force-pushed
the
ad_group_type_man_update
branch
from
4a23826
to
6749df2
Compare
src/man/sssd-ad.5.xml
Outdated
| forest. By default they are filtered out e.g. when following a | ||
| nested group hierarchy in remote domains because they are not valid | ||
| in the local domain. This behavior is dependent on the value for | ||
| the <quote>ad_allow_remote_domain_local_groups</quote> option |
There was a problem hiding this comment.
Hi,
thanks for the update but please remove the last sentence. This option should not get any additional attention. And I would like to ask you to add a sentence like "This is done to be in agreement with Active Directory's group-membership assignment which can e.g. be seen in the PAC of the Kerberos ticket of a user issued by Active Directory."
bye,
Sumit
There was a problem hiding this comment.
Done, thanks.
Linux admins/users may not know that the AD distribution group type is intended only for email. Per microsoft: Distribution groups are not security enabled, which means that they cannot be listed in discretionary access control lists (DACLs).
justin-stephenson
force-pushed
the
ad_group_type_man_update
branch
from
6749df2
to
42a4add
Compare
|
Backport/no backport? |
Forgive the ignorant question, but do I determine if it needs to be backported or not? This PR originates from a RHEL9 BZ |
|
If there is rhel9 BZ that is fixed by this commit then it should be backported to 2.7 so Alexey can push to rhel9. If it is just a side job that is not going to rhel9 then backport is not required. |
backport set, thank you. |
|
@justin-stephenson, could you please add a link to the RHBZ in the comment of this PR? |
justin-stephenson
added
no-backport
Done and set 'no-backport' |
Linux admins/users may not know that the AD distribution group type is intended only for email. Per microsoft:[1] Distribution groups are not security enabled, which means that they cannot be listed in discretionary access control lists (DACLs).
[1] https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/active-directory-security-groups