cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1442
Views
30
Helpful
6
Replies

UC Platform sync with OKTA instead of Microsoft AD

JasunKAR
Level 1
Level 1

Hello!

 

We are putting in a 12.5 cluster and in the past i've always used MS AD as the source to sync accounts into CM.  We've been tasked with using Okta as the source to sync accounts into CUCM/CUC instead of AD (and use Okta as our SSO too).  

 

I assume this would be configured the same way since i'm told Okta will respond to LDAP queries just like AD.  Has anyone ever done this before with Okta?  Looking to see if anyone has pro's/con's to using Okta rather than AD.  

6 Replies 6

Jonathan Schulenberg
Hall of Fame
Hall of Fame

What a great question; I’m curious to see if others chime in with experience - I haven’t heard of a customer doing this before. This should be fairly easy to test out in the lab at least. CUCM/CUC support any LDAPv3 server at this point.

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/collab12/collab12/directry.html#pgfId-1067953

 

One common challenge with anything other than Active Directory is the lack of an ObjectGuid attribute. Without this username changes appear as a new End User in CUCM with the old account becoming inactive/deleted. In the case of Okta you would of course need to use TLS but that should be easily accomplished.

 

You would also want to use UDS to avoid Jabber hitting Active Directory. That carries the normal limits of UDS (eg loss of ANR (AD only), load impact on CUCM, loss of otherTelephone attribute in secondary number lookup, inability to search for enterprise groups, etc). Remember that UDS is mandatory for MRA-connected clients so it’s not like you’re avoiding it entirely.

 

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/collab12/collab12/directry.html#pgfId-1067953

Hmm I don't see ANR being a super big issue, but we'll see.  MRA will be a thing though so that is good to know.  

 

I guess if we go the Okta route I may try to write up something and attach here for the next person who stumbles down this path!

 

Thanks for the feedback Mr. Jonathan!


@Jonathan Schulenberg wrote:

One common challenge with anything other than Active Directory is the lack of an ObjectGuid attribute. Without this username changes appear as a new End User in CUCM with the old account becoming inactive/deleted.


I kicked the tires on this, and here is what I found:

 

You're correct that Okta does not expose the AD objectGUID attribute.  It appears, though, that there is a 'uniqueIdentifier' attribute (Okta documentation suggests they use 'externalID', but my own experimentation found otherwise).

 

So looking under the hood at how DirSync works, I found that it treats "LDAP Server Attribute" 0 as the unique & immutable attribute to track username changes:

admin:run sql SELECT * FROM typeldapserverattr WHERE enum = 0
enum moniker name displayname displayed tkcustomuserattribute displayorder
==== ===================== ================ =========== ========= ===================== ============
0 LDAP_SERVER_ATTR_IDEN UniqueIdentifier null f NULL 0

 

Out of the box, CUCM only sets an attribute for this for AD and ADAM directory types, as you point out:

admin:run sql SELECT * FROM ldapserverattribute WHERE tkldapserverattr = 0
pkid tkldapserver tkldapserverattr dirobjectname
==================================== ============ ================ ================
51923ce0-f5d1-4a37-8624-baf05fa13b06 1 0 ObjectGUID
9016a2d8-da97-4967-b357-32447b2d04cc 2 0 NULL
f44ce742-30a5-4488-8174-a398e4a18800 3 0 NULL
c49faebb-84ed-400e-9556-951ea501b243 4 0 ObjectGUID

 

I was kicking the tires for this on a CUCM 10.5 system which didn't have generic LDAPv3, so instead I used OpenLDAP which is tkldapserver = 3.  I modied the table above such that dirobjectname = 'uniqueIdentifier'.  Since I had already configured LDAP and CUCM didn't do the work for me, I also insert a record in to directorypluginattribute so DirSync would start actually using this:

admin:run sql SELECT * FROM directorypluginattribute WHERE tkldapserverattr = 0
pkid fkdirectorypluginconfig dirobjectclassattrname tkldapserverattr
==================================== ==================================== ====================== ================
678cec6b-0726-4d41-b8e2-5bf916d3a661 20a5b807-7a77-4ec5-cff5-2c48fb159033 uniqueIdentifier 0

 

Now I can change usernames without issue, because (as you can see) the CUCM database table enduser now has a value for column uniqueidentifier:

admin:run sql SELECT * FROM enduser WHERE userid = 'joseph@nevosi.com'
pkid assocpc firstname middlename lastname userid manager department telephonenumber tkuserlocale mailid status facsimiletelephonenumber mobile pager homephone title building site fkdirectorypluginconfig uniqueidentifier nickname deletedtimestamp passwordreverse fkmatrix_presence tkuserprofile fkcallingsearchspace_restrict allowcticontrolflag enablemobilevoice maxdeskpickupwaittime enablemobility remotedestinationlimit ocsprimaryuseraddress enableemcc fkucserviceprofile directoryuri islocaluser fkucuserprofile enablecalendarpresence enablecups primarynodeid keypadenteredalternateidentifier discoveryuseridentity
==================================== ======= ========= ========== ======== ================= ======= ========== =============== ============ ================= ====== ======================== ============ ===== ========= ========= ======== ==== ==================================== ==================== ======== ================ ================================================================ ==================================== ============= ============================= =================== ================= ===================== ============== ====================== ===================== ========== ================== ================= =========== =============== ====================== ========== ============= ================================ =====================
e8e44314-584e-84dd-15b9-c4d9dc856caa Joseph Testuser joseph@nevosi.com 1999 NULL joseph@nevosi.com 1 +15135553000 Test User 20a5b807-7a77-4ec5-cff5-2c48fb159033 00ubgg0seRe5tMXWY4x6 NULL 1dcdf258568eb1209c029d19661bff5d10ce038319364f62c96b72e5cf622c8f ad243d17-98b4-4118-8feb-5ff2e1b781ac 1 NULL t f 10000 f 4 f NULL joseph@nevosi.com f NULL f f NULL NULL joseph@nevosi.com

 

I have not yet fully fleshed this out yet to determine if there are any other kinks (will this survive upgrades or need to be repeated?) but did want to share what I have found thus far in case anyone else was kicking the tires on Okta.

Good info!  We ended up going the ol trusted AD route.  So OKTA and AD are in sync then we sync off AD with an ad filter to only allow people of a certain security group to sync in so we don't get all the garbage accounts.  

Very helpful!

Someday, I will probably need to migrate from our current Active Directory sync to Oracle IDCS via an "other LDAPv3".  

I'll need to do some research as to whether they have a "ObjectGuid"-type value that could be tapped.

Hi @jdiegmueller  

This is excellent. Thanks for sharing it. Did you just do a SQL injection to update the attribute for the ldap server? Do you mind sharing your steps? And how did you generate the unique attribute? Random combination?

Please rate all useful posts