Forum Discussion
AADconnect synced security groups vs. teams mess
Hello everybody, we are using office365 in combination with our local on-premise AD for some months now. In this setup, our staff is (historically) grouped into several on-premise security groups...
Thank you very much for your quick response. One (more question) ...
... I am working at a school with round about 120 teachers and 1200 pupils (grouped into approximately 50 classes) ... all this people are grouped into a huge amount of on-premise security groups, to manage corresponding permissions and services in our local (windows 2016) AD.
By start using AADconnect, als these users and groups are synced into Azure AD. As you mentioned before, on-premise (and mail-manged) security groups are not synced into corresponding office365 groups in Azure AD. At this point, the reasonable use of AADconnect gets questionable to me. Basically I would like to manage all my users and groups in our on-premise AD (which gets synced). For example all teachers are grouped into an on-premise group „Teachers“. If I correctly understand your advice, one should create a seperate office365 group (lets call it) „Teachers-Office365“, but in this setup, all later on-premise variations to the security group „Teachers“ do not get synced to „Teachers-Office365“ by AADconnect.
This design seems to be contradictory to the basic value of tools like AADconnect ... ?
Thanks for your advice,
Michael
You are correct in your statements!
You can have a look at dynamic office 365 group membership! You can then have dynamic membership based on attributes in AAD, possibly also synced from AD
https://docs.microsoft.com/en-us/microsoftteams/dynamic-memberships
You can have a look at dynamic office 365 group membership! You can then have dynamic membership based on attributes in AAD, possibly also synced from AD
https://docs.microsoft.com/en-us/microsoftteams/dynamic-memberships
Thank you for your (clarifying) elucidations! The point is, that this construct/design seems not very elegant to me (as a former student of computer science) ... so i would not have believed that a tech giant like microsoft does not offer a more carefully thougt-out design to its customers for linking on-premise ADs to Azure (and Office 365).
So clearly I can (must) create office365 groups by dynamic membership to synced Azure AD attributes, but my original comprehension of AADconnect was to manage for example the creation (and membership) of (possible) hundreds of on-premise groups (classes, courses, ...) in our local AD and sync them afterwards to Azure AD. If you are right (and I think so), this leads to a double-entry accounting in some sense.
For example if one needs/creates a new set of on-premise security groups, all these groups have to be created a second time as office365 groups (or teams) in our Azure AD (e.g. by the use of powershell-scripts?). In addition to that, one has to administrate a corresponding set of Azure group membership rules to guarantee the desired (dynamic) membership between synced on-premise groups and corresponding office365 groups ... what seems curious to me.
Would it be a better approach to use features like „Group writeback“, that means, create and manage all groups as office365 groups in the cloud (once) and use this accounting in our on-premise AD?
But as I see here ...
... the group writeback feature only creates distribution lists (on-premise)?!?
Thanks a lot,
Michael
Few clarifications from me as well. First of all, O365 Groups are NOT a security principal, they cannot be used to assign admin roles or permissions. Next, they are "cloud" object, with no analog in on-premises AD. The only AAD Connect feature that relates to groups is the "group writeback" one, which by itself is more of a hack to enable some scenarios. So your expectations of being able to manage O365 Groups/Teams via corresponding AD groups simply cannot be met, by design.
You can use PowerShell or the Graph API to automate some of the tasks around populating membership, however you will still end up with separate objects on-premises and in O365. Where AAD Connect remains useful is the management of the user objects, "traditional" groups, configuring SSO and so on.
