I have spent the best part of 3 weeks wrestling with CUCIMOC. It’s fair to say I haven’t been the biggest supporter of this particular piece of software during this time. I respect the feature set, but I can dial a colleague with almost as few clicks on the handset as easily as I can through cucimoc, and the same goes for creating conference calls etc.
One document I would say is prescribed reading is this article. It holds loads of information, but imho is not very clear about valuable points.

Out of the box, getting the integration with CM7 was quite simple, we put the necessary framework devices in place, logged into CUCIMOC with telephonenumber and ‘pin’. All good, or so we thought….
Then we went through the process of integration the CUCM7 servers with AD, opting to use telephonenumber as the primary login mechanism for handsets (who wants to tap out first.last on their 7960 when they use extension mobility!!)
Straight after that, the CTI control of the hard phone (7940/7960) instantly broke. The softphone option would work on occasion, but we simple couldn’t get the  hard phone to work again.
A long week of trying various things in our test lab it all came down to the selection of login choice, pin number and password. We are currently CUCM4.x users and in that environment we use pin and password interchangeably, but in CM7 with ldap/AD integration, they become 2 separate items, your pin logs you into a hard phone device and your password is integral to anything you sign into under software emulation of phone devices.
Armed with this in our heads, we went back through our CUCM7 (with AD integration) config, placed all the framework services into the system, then logged into CUCIMOC with telephone number, and password. Hooray RCC/CTI works!

So, that working reliably and predictably, we moved onto the final section of getting ldap to work from the client for CSF data. The CSF data comes into play when someone rings you who isn’t in your Outlook contacts, isn’t a MOC user, but is held in your directory. CSF facilitates that you get a name to reflect against an incoming phone number. This is done via your client talking ldap to AD to retrieve a name for the phone extension. I have done several attempts at getting this to work, but each time I ended up with a disconnected session in the ‘server status’ section of CUCIMOC.
I used wireshark to sniff this conversation, and saw I was getting: W80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 52e, vece.
Several Googles later I was left confused, was this indeed a context auth error, a password error or an invalid Kerberos token. I went over the wireshark packet trace again and noted that although my username etc was parsing correctly, the password had ’123456′ in clear text. This is the pin i was using in the test lab! So here it was passing correct AD creds with pin number. I changed the login field to use telephone number etc and got variants of these pair of pin/password/extension no/sAMAccount. Never the combo I needed!
I kept putting ldap://<ldapservername> into a browser and would get an error like this:

I then went over the sample data offered with the CUCIMOC client (cucimoc-Admin-ffr.7-1-3.zip) and in particular the file held in ..\Config\SampleCUCIMOC-CUCSFAdminData.bat file.
This clearly defines what entries you will need for stand alone or ADM configured machines via policy. Not only this, but it provides a means (via the batch file) for deploying these settings in basic login scripts etc.
I studied these values, comparing them over and over again with my own, held in my HKCU registry. I could see nothing that helped me, but I keenly tried any variant I could think of. One key kept jumping out at me though, as something I would need to give careful consideration, namely: POLICY_CREDENTIALS_IsLdapSynchronizedWithCucm. Now I’d always assumed that as we had integated CUCM integrated into AD, I would have to have that set to true, and so I did. Again, rebooting between each change to be sure they were taking effect, I was unsuccessful.
So I went back to wireshark/thinking/reading and discussing. A chance conversation with our CUCM Admin, got me closer to the pin vs password conundrum I highlighted above. they are 2 different things in CUCM7 integrated to AD. I was used to CUCM4.
I went back to CUCIMOC and logged it in correctly, with my phone extension as the username and my AD password as the password. Hoorah, MOC logs in, phone control works for CTI and softphone, but… ldap is still disconnected.
I started to read the documentation again, thinking about pins/passwords/samaccountname/userprinciplename/telephone number etc. I then re-read this article which made me start to think about the POLICY_CREDENTIALS_IsLdapSynchronizedWithCucm string value. What if I changed that, that would allow me to specify ldap creds surely.
Changing this to ‘false’ then provides exactly the change highlighted in the document, specify samaccountname and password and bingo.. ldap working at last!
Something I was struggling to find during this little process, was a WORKING example of the registry settings, so hopefully to save you some pain, here are mine.

Why isn’t this documented more clearly, if you make the seemingly inane choice to use telephonenumber as your login mechanism of choice whilst integrating CUCM with AD, you set in place your inability to get ldap to auth properly without having to specify a username and password seperately for client ldap, and you HAVE to set POLICY_CREDENTIALS_IsLdapSynchronizedWithCucm=”false”

Hurrah it works! I’ll not get those tedious hours of my life back though….