Jul 06 2019 10:26 AM - edited Jul 06 2019 10:27 AM
Jul 06 2019 10:26 AM - edited Jul 06 2019 10:27 AM
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 in the local AD, which get synced into the Azure AD, corresponding to our office365 tenant.
In the last few days, i played around with Microsoft Teams (created some teams, etc.). My (naive) idea was to create some teams in the following way:
1.) In our local AD exists (for example) a mail-enabled security group called „Administration“ with corresponding group-mail address „email@example.com“ (Exchange).
2.) In Microsoft Teams, i created a team called „Administration“ and invited all members of the security group „Administration“. In this setup, i observed that the creation of the team „Administration“ caused the automatic creation of a corresponding office365 group called „Administration“.
The latter point seems confusing to me. One the one hand, dirsync tools like aadconnect should make it possible to reuse classical on-premise groups in the office365 context. On the other hand, this gets an organisational mess, in combination with Teams (duplicated Office365 goups vs. dirsynced groups as described above).
I already found out, that a owner of a existing pivate office365 group is able to associate this group to a corresponding team in Microsoft Teams. In my setup (we are talking of dirsynced, mail-enabled security groups of the on-premise ad) this seems not possbile.
At this point, I would be very grateful for any advice to the questio, how to design a reasonable interaction of synced on-premise groups in combination with office365 teams.
Thanks to everybode for some advice/experience,
Jul 06 2019 10:41 AM
Jul 06 2019 11:52 AM
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,
Jul 06 2019 12:26 PM
Jul 06 2019 01:39 PM - edited Jul 06 2019 01:46 PM
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,
Jul 07 2019 09:12 AM
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.