Level 1 Users as AD groups

[deleted-user-FfGbgR253rTy]

I would like to be able to use Portal, but am in an organization with hundreds/thousands of users (depending on the organization level). Is there any way to do this other than have two set-ups?

With the new levelled user option, and in Enterprise, can you set up a Level 1 user that includes a large Active Directory group? (assuming windows etc.) Or does adding an AD group still just add all the members as individuals?

Thanks

[MarleyGeddes]

Hi Cameron, 

Can you clarify what requires two setups, or separate portal configurations?

You are not able to set up a single user that includes an Active Directory. Each individual member of your Active Directory requires a Portal License (level 1 or level 2) to be a member of your Portal.

Hope this helps,
Marley

[deleted-user-FfGbgR253rTy]

It's not cost effective or practical for me to pay for hundreds or thousands of level 1 users that may or may not ever need to access a web map, but should be allowed to access it. 
With ArcGIS Server (not Portal/ArcGIS Online) I can secure services by using AD groups, but I don't have any tools to author the web maps. (outside of increasingly outdated Silverlight builder, or the somewhat kludgy ArcGIS WebApp Builder for javascript, locally installed, with the hacked on LocalLayers widget) 

With Portal or ArcGIS Online, I get all sorts of tools, but I'm locked into only being able to allow access to named users or the public, with nothing in between to account for the organisation. This results in these tools being limited to smaller project teams, as opposed to any organisation or enterprise level map creation.

So, if I want to build web-maps for groups that are too large to feasibly manage in ArcGIS Online or Portal, I need to have ArcGIS Server set up on it's own (i.e. without Portal), but, if I want to be able to build web-maps in a modern web-app builder, I need to use ArcGIS Online or Portal...

If there was a way to consider an Active directory group as a named user (maybe only in Portal), I could work with it. I'd still need to purchased a "named user" account for every seperate AD group I wanted to add... but it would allow me to bridge the gap between public and project access.

[JonathanQuinn]

You may want to look into SAML, which would give you the single sign-on experience as well as allowing built-in users/anonymous access to the portal.

[deleted-user-FfGbgR253rTy]

Will look at it... Didn't think it was as much a technical issue as a licensing agreement issue though... (i.e. can I have a single user in Portal or AGOL called "MYGROUP" and have all the members of that group able to view a web map restricted to that group?) We already have single sign on with our AGOL.
Providing a single account and password to multiple people is against our internal security policy, and, to my understanding, against the terms of our ESRI agreement...

[JonathanQuinn]

Yes, sorry if my post made it seem like I was suggesting that.  It's certainly against the license agreement to share a single account with multiple people, but configuring your portal with SAML authentication will give you the ability to take advantage of Windows accounts for users who require a named user in the portal but also gives you the ability to grant anonymous access to your portal for users who don't need a named user and just need to access a webmap.

[deleted-user-FfGbgR253rTy]

The danger with anonymous use is security. I need to be able to expose web maps to both secure groups of external users, and internal groups of users, but many of these groups are large enough to make purchasing named user accounts impractical. With the traditional server set up, it's do-able, and I don't have to worry about managing the members of AD security groups already in use for the project, or purpose (which can be a surprisingly big task on it's own).

In short, named users are fine, but you need to have a model that supports large groups of users (preferably existing groups so we don't have to manage group membership in multiple places) so that enterprise implementation is practical. Annual pricing on everything is also problematic in this type of scenario.