using stored procedures to work with ad integration

[stephan.steiner]

Hi

Rather than to wait for ldap sync (which we can't trigger, let alone trigger for a given samaccountname), I'm trying to figure out if there's a way to do things directly in the database.

However, with the hundreds of SPs and even more tables/views, that's quite a tricky job. So I'm wondering if somebody could point me to the right direction.

Here's what I want to do

1) add a user from ldap if the ldap sync has not yet run. I can provide objectguid from ad, the ldap profile name, samaccountname, upn. What's the SP to be used? (and there's probably some lookup to get a guid for the ldap profile)

2) change userid of a user that is ldap integrated (or alternatively, convert ldap user to local user so that I can use the rest api to update, then convert back to ldap synced user)

Thanks

Stephan

@edit: I did some digging around in the database - vw_subscriber seems to have the attributes I care about: ldapccmpkid, ldapccmuserid and ldaptype. LdapType defines the LDAP integration, ldapccmuserid is the samaccountname, but I don't unserstand ldapccmpkid. In the CUCM enduser database, the field that maps an enduser to an ldap user is uniqueidentifier, and it's an octet version of the guid used for objectGuid in AD. The ldapccmuserid seems to be an entirely different GUID though. I don't necessarily need to set that value though, perhaps the other two will suffice.

@edit2: I think I'm on to something:

execute procedure csp_subscribermodify (pLdapCcmUserId='humstermann',pLdapType=3,pObjectId='4f5ab16f-a1f4-4c72-9a88-6e95bf92e59a')

Will enable ldap integration, and

execute procedure csp_subscribermodify (pLdapCcmPkid=NULL,pLdapCcmUserId=NULL,pLdapType=0,pObjectId='4f5ab16f-a1f4-4c72-9a88-6e95bf92e59a')

seems to be disabling again. Now off to test if once disabled, I can change the name with cupi and then for the real test.. a new user that hasn't been synced yet.

[stephan.steiner]

I'm afraid I've hit an impasse.. even though I can create local users, then seemingly convert them to ldap synced users using the queries above, the ldap sync doesn't pick up the pieces and ties everything together (a proper ldap synced user also has the ldapccmpkid set it seems.. otherwise the gui will show it as ad enabled, but it won't pick up changes from ad).

So, for the create case, how would I go about getting that pkid?

And for an update - the same story. If I have a samaccountname change, this will result in a new user being created, and at the moment, you need to detach the user from ldap, change alias, then re-attach. You can do that using the GUI, but not the API and not the database since you're lacking the ldapccmpkid value for the new data that was imported from ldap.

And as I understand it, that "seamonkey" database that holds the ldap users is not part of unity so there's no external access to it to look up that guid value. And without that, my whole idea is at a dead end. Or am I missing something?

[lindborg]

it's "sea dragon" (although I prefer sea monkey myself) - and no, it's no longer available from off box (it used to be via a SOAP protocol but they locked it down for security reasons along the way).  It uses a completely separate database instance (i.e. so you can't do ODBC connections to it via our proxy) - so the only way to communicate with it - adding user mappings and such - is via a back end process that does direct calls - not something you can tickle from off box via your own scripts I'm afraid.

to gain access to it another "proxy" type service would need to be put in place to pinwheel commands over to it like we do for the ODBC access.  This is not trivial, of course, and would likely not make it past the security board at any rate.

[stephan.steiner]

Oh yeah, I noted it's dragon not monkey. I guess from all the monkeying around in the database I turned a dragon into a monkey

So in other words, there's no way to do what I want to do, right? And thus I just have to pray and hope for my feature request to bring AD integration feature parity between cucm and cucn (Feature Request: Feature Party in AD Integration between CUCM and CUC) will eventually be implemented.

I wonder why it uses another pkid.. objectguid seems the obvious choice (cucm does use it, and so do my own apps that integrate with ad).