#1 2009-11-13 08:49:19

**_tlchurch_**

Migrate Internal Connect Users to LDAP/Header Authentication

I have to migrate about 2,000 users from internal Connect accounts (logging in with their email addresses, Connect password) to external LDAP accounts with header authentication (logging in only with their domained accounts). Another 3,000 users will remain internal to Connect (not LDAP users).

Has anyone else gone through this process? Recommendations, pitfalls, etc.?

Other questions:

- With LDAP synch enabled, what happens when a user is removed from the domain? Are they automatically removed from Connect as well? Is there a way to notify the administrators when this happens so we can clean up user content?

- What happens if the LDAP server is unavailable when Connect tries to synchronize?

- Does the LDAP synch take Connect offline at all or make it sluggish in response?

We'll be going through tests of these questions and many more, just wanted to check if anyone already knew the answers. Thanks!

**_ddumaresq_**

Re: Migrate Internal Connect Users to LDAP/Header Authentication

Hello,

I realize a couple years have passed since you posted this question; I am about to embark on a similar project (smaller scope) and wonder how you managed with the migration?

Regards,
Dave Dumaresq

**_tlchurch_**

Re: Migrate Internal Connect Users to LDAP/Header Authentication

Hi Dave,

We ended up writing a script that would look up a user's name in the LDAP to determine the correct username (since we started with their email, which may or may not have correlated directly with their domain username). Then updated the Connect profile (automatically via the API). Once we finalized the script, the actual automated migration was easy -- push a button and wait for the users to be updated, then test that the LDAP password worked, then set the password field in Connect to NULL for those users (since we still had Connect fallback authentication enabled for a set of users, we wanted to make sure that this group of users could ONLY use their LDAP passwords).

The answers we found to the questions I originally posed are:
- With LDAP sync enabled, if a user is removed from the domain, there is a setting in Connect whether to remove them from Connect as well. Have not found a way to notify the adminsitrators other than viewing the sync log file. We did not enable this option, as the LDAP sync in our case frequently tags someone as no longer in LDAP even though they actually still are. (We are working with Adobe to determine why that is the case - probably has something to do with the size of the sync).

- If LDAP server is unavailable during a sync, there is no sync. I have not seen services fail when this happens, however if a LDAP error occurs during the sync, that has occasionally taken a service offline temporarily.

- LDAP sync is resource-intensive, but Connect is still operational. Occasionally makes a server unavailable for us, but we have more than one so this was not an issue. That said, we sync at 1am to minimize user impact.

**_ddumaresq_**

Re: Migrate Internal Connect Users to LDAP/Header Authentication

Thank you for your reply, Teresa.
You've given me a valuable suggestion, that we use a script to convert existing users' login from email to username.
I am interested to see you're also using header authentication (as we are)... I was confused about why LDAP passwords are still required, but now understand LDAP authentication is required to perform group and internal account operations. 
We are having problems with our LDAP provider (ApacheDS) authenticating dynamic users from our database. We're getting an Operations Error (code 1) and believe it has to do with the connection to the database closing before LDAP has completed the authentication... 
If you have any suggestions, I appreciate the contact with some else who has gone down a similar road.

Thanks,
Dave

**_jbourke_**

Re: Migrate Internal Connect Users to LDAP/Header Authentication

Hi Teresa,

While I am not the Connect Admin myself (I'm the infrastructure guy rolling out the product), you describe an issue and situation we are hitting perfectly, i.e. migrating Connect internal users to LDAP auth and changing user login emails to Principle names.

We are having some trouble with successfully scripting this (in particular which fields to change). Is the following correct:

UPDATE PPS_PRINCIPALS set LOGIN='<the-userPrincipalName-value>', EXT_LOGIN='<the-userPrincipalName-vale>' where LOGIN='<old-email-value>';

Would you mind sharing your script with us, or pointing us in the right direction?

Regards,

Jonathan

**_ddumaresq_**

Re: Migrate Internal Connect Users to LDAP/Header Authentication

I second that request. It would be very helpful for us too, if you could share your script.

Thanks,
Dave

**_tlchurch_**

Re: Migrate Internal Connect Users to LDAP/Header Authentication

I did it primarily in two steps: update the username via the API, then "externalize" the user in the database. As a 3rd step, I removed the internal password stored in Connect to force the user to only use their external credentials.

I used the API to update the login field value:
Call =

[Server URL]/api/xml?action=principal-update&principal-id=[XXXX]&login=YYYY

[XXXX] = User's principal id from PPS_PRINCIPALS.PRINCIPAL_ID (same as PPS_USERS.USER_ID)
[YYYY] = New login

Then executed:

UPDATE PPS_PRINCIPALS
SET TYPE=11 -- External user
WHERE PRINCIPAL_ID=[XXXX]

To clear the internal password:

UPDATE PPS_USERS
SET PASSWORD=NULL, DATE_KEY_EXPIRES=NULL, PASSWORD_KEY=NULL, PASSWORD_EXPIRES=NULL
WHERE USER_ID=[XXXX]

Hope this helps.

**_ddumaresq_**

Re: Migrate Internal Connect Users to LDAP/Header Authentication

Thanks Teresa. Much appreciated!

**_Capt_Ron_**

Re: Migrate Internal Connect Users to LDAP/Header Authentication

Teresa,
I hate to ask a dumb question but...

The API call.  I've never done an API call before.  Where do I do this?
Thanks
Ron

**_tlchurch_**

Re: Migrate Internal Connect Users to LDAP/Header Authentication

Ron,

You can do an API call from many places - directly in your web browser, or from code.

Information on Connect's API can be found at Adobe's developer center http://www.adobe.com/devnet/adobeconnect.html

For Connect 7, the API documentation is at http://help.adobe.com/en_US/AcrobatConn … rvices.pdf

**_Capt_Ron_**

Re: Migrate Internal Connect Users to LDAP/Header Authentication

Thank you.
I can do this from a C# or VB.net app.  Perfect.

Much appreciated.

Did this keep the user's content attached to their logins?

Thanks
Ron

**_tlchurch_**

Re: Migrate Internal Connect Users to LDAP/Header Authentication

Great.

Yes, everything is tied to the user's principal id; changing the login will change the content and meeting folder names for the user but all permissions, links, etc. will remain active.

**_ddumaresq_**

Re: Migrate Internal Connect Users to LDAP/Header Authentication

I did it primarily in two steps: update the username via the API, then "externalize" the user in the database. As a 3rd step, I removed the internal password stored in Connect to force the user to only use their external credentials.

I used the API to update the login field value:
Call =

[Server URL]/api/xml?action=principal-update&principal-id=[XXXX]&login=YYYY

[XXXX] = User's principal id from PPS_PRINCIPALS.PRINCIPAL_ID (same as PPS_USERS.USER_ID)
[YYYY] = New login

Then executed:

UPDATE PPS_PRINCIPALS
SET TYPE=11 -- External user
WHERE PRINCIPAL_ID=[XXXX]

To clear the internal password:

UPDATE PPS_USERS
SET PASSWORD=NULL, DATE_KEY_EXPIRES=NULL, PASSWORD_KEY=NULL, PASSWORD_EXPIRES=NULL
WHERE USER_ID=[XXXX]

Hope this helps.

Hi Teresa,
Can you explain how you got the principal-id? I know you said that you started with the email address from the LDAP directory...is the principal-id also stored in your LDAP directory?

Thanks,
Dave

**_tlchurch_**

Re: Migrate Internal Connect Users to LDAP/Header Authentication

We did all users at once so I pulled principal-list from the API and iterated through each principal.