ArcGIS Online ADFS Integration

5372
10
Jump to solution
04-04-2014 07:19 AM
MikeBenson1
New Contributor II
Hello,

I am looking for any information available in how existing AGOL Organization user accounts, user published content and group memberships migrate when the individuals Active Directory account is integrated with AGOL.

Is there the capability to map an existing AGOL account to the new AD account?

Does Esri provide an automated mechanism to migrate user published content and group memberships from the existing AGOL account to the new AD account?

If the migration is a manual process, are there any recommended best practices to follow?

Thanks in advance for any suggestions or responses.

Mike
Tags (2)
0 Kudos
1 Solution

Accepted Solutions
MikeMinami
Esri Notable Contributor
There is nothing currently built into ArcGIS.com to move users in an automated fashion. The admin can manually move items from one user to another, then delete the previous user. There are some python utilities here that may be worth looking at.

https://github.com/Esri/ago-tools

Note that while people have success with these tools, they are unsupported by Esri.



Thanks,

Mike

View solution in original post

0 Kudos
10 Replies
MikeMinami
Esri Notable Contributor
There is nothing currently built into ArcGIS.com to move users in an automated fashion. The admin can manually move items from one user to another, then delete the previous user. There are some python utilities here that may be worth looking at.

https://github.com/Esri/ago-tools

Note that while people have success with these tools, they are unsupported by Esri.



Thanks,

Mike
0 Kudos
deleted-user--EOLRcEP5EU5
New Contributor

Mike,

Can I retain my original AGOL accounts while making the transition to AD?

Or once I establish ADFS as the identity provider, can my users no longer login with AGOL accounts to our Organization

0 Kudos
MikeMinami
Esri Notable Contributor

Yes, you can maintain both your AD accounts and AGOL accounts. They are considered separate accounts. Now, you'll probably want to consolidate, as each account consumes a "named user" in the subscription.


Thanks,

Mike

0 Kudos
DavidRunneals
New Contributor II

We are in the process of rolling this out to our organization, and we have been using the firstname.lastname_<org_ID> already with the AGOL Enterprise Login. If we configure our NameID to be firstname.lastname_<org_ID>, will users be able to login to their already established accounts, there by making the roll out 100x easier?

Also related, would creating a pre-established account for users with the same NameID that would be coming from AD allow users to get to the already pre-established account?

0 Kudos
TimHaverland4
New Contributor III

Hi David, we are in this exact same situation, having named all of our accounts with the <NameID>_<org_ID> convention (which is the default behavior when creating new accounts manually).

Have you learned anything new about how these existing accounts are handled in the enterprise login process?

Tim

0 Kudos
MikeMinami
Esri Notable Contributor

Unfortunately, you can't can't configure your enterprise logins to use the same username that already exists in AGOL. If you do this, the enterprise login will fail because a username already exists.

However, this is a good idea and I'll write it up as an enhancement. I'm not sure what it would take to do this, so no guarantees...

Mike

0 Kudos
TimHaverland4
New Contributor III

Hi Mike,

Thanks for the reply and for offering to submit this as an enhancement. I would think this is a pretty common occurrence since the default AGOL organizational account naming convention uses the username of the new user's email address, and that username is typically an organization's enterprise login username.

One clarification: if an enterprise AGOL account name already exists, will the login fail, or will AGOL create a unique username using the patten <NameID>_<OrgID>? For example, if tim.haverland_noaa exists AGOL will create an account name like tim.haverland9_noaa?

This has important implications for how we plan for a migration to enterprise logins.

Tim

0 Kudos
MikeMinami
Esri Notable Contributor

Just to be clear, you have created logins for AGOL that don't use enterprise logins. Now, you want to activate enterprise logins and use the same username that exists already in AGOL. Attempting to login with an AD login that matches an existing AGOL login will fail. The system won't try to create a new one.

I spoke with our developers here and they said in order to implement active directory you could

"change the NameId saml attribute that is returned from the IDP to be something other than what they were sending so it would not conflict with the existing usernames."

This means modifying what Active Directory does, which could impact other things in your organization. The only other thing I can think of would be to introduce another manual process of creating new usernames for all employees, transferring existing content to that username, then to delete all the old usernames, then activate enterprise logins and sign in again and transfer all content.

not the best news...

Mike

TimHaverland4
New Contributor III

Thanks for checking on this Mike.

Yes we have been using AGOL for a couple of years now and because we didn't have an identity provider until recently, we have used the default invite process to create non-enterprise accounts, which bases the AGOL account names on the user's email username appended with "_" and our org name.

Now to be more secure and to simplify our account management we would like to go to enterprise logins.

I will check with our ID provider to see if they can change the NameID for just our ArcGIS Online org. If this is possible, then I think we could write a script using the REST API to periodically check for new enterprise logins, migrate the old content to the new account, deactivate the old account, and notify the user when the process is complete. At some point we would delete the old accounts.

Of course it would be great if the enterprise login process could recognize that a matching account exists within the organization and work some magic to change it from a "local account" to an "enterprise account." I suppose if accounts weren't named properly to begin with you could have mix-ups (like mike.brown vs michael.brown), so there would have to be either an admin sign off on the process or the user would have to enter their old account credentials.

May be simpler just to bite the bullet and migrate to new account names.

Tim