LDAP - need to use objectGUID for my application


For a specific (third party Windows) application that is really only intended for use with Active Directory, I need to be able to use the objectGUID attribute on our UCS LDAP. I’ve got almost everything in working, including some schema extensions that where needed (took me a lot of time to figure out) but now I’m stuck on the objectGUID. This application needs to get the objectGUID from the LDAP to work, but right now the objectGUID attribute is not assigned nor can I add it to a contact or user because apparently the attribute does exist as I get the message that it is immutable.

Is there any expert out there that can help me achieve my goal:

  • add the attribute ‘objectGUID’ to (at least) the contacts in my LDAP
  • have it so that new ‘contacts’ also get this attribute
  • have it behave like it would on AD where it is universally unique

Help is much appreciated…

Some background info, probably not needed for the issue I have …

The application is a voicemail system from Avaya (a well known enterprise UC vendor). The application needs to get configuration details from AD (or in my case LDAP) to be able to add its mailboxes. There is no way I can have the voicemail system use a different attribute then the ‘objectGUID’ - there is no configuration option available, nor will Avaya help me since it’s not supported (ie. they cannot/will not support the application when it is not used as it is intended). Soooo close…

Kind regards,


I could imagine that you have already thought about that, but have your already installed the “Active Directory-compatible Domain Controller” App a.k.a. Samba on your UCS?

If Avaya is so “stubborn” on wanting a unique identifier specifically in the objectGUID attribute, then that would be the easiest in my opinion. Don’t point Avaya towards OpenLDAP on Port 7389, but on 389 where Samba listens, that might do the trick.

Keep in mind, that while Samba AD does a pretty good at behaving very similar to a Microsoft AD, there are still minor differences that can break third party support (I’ve been there in the past). I could imagine very well, that whenever you run into an issue with Avaya and open support tickets about AD integration, that they might not bother helping you because of it not being a “original” MS AD.

Thanks for the reply… In the past I’ve used the domain takeover function of UCS and that completely changed the LDAP schema. I’ve thought about installing SAMBA but I’m affraid it will also screw up my existing LDAP configuration… Not sure what the effect would be of ‘simply installing’ SAMBA, so I need to check and make sure… (obviously a VM snapshot will save me in the end)…

Hi, the Samba “App” actually installs Samba and the S4 Connector, a replication between OpenLDAP and the Samba 4 AD LDAP. It is likely (I don’t remember exactly) to add some attributes so that some elements can be synced into the OpenLDAP directory and thus can become visible in the UCS Web UI.[1] However it doesn’t affect the structuring of the directory, that I’m certain.

A VM snapshot is nonetheless a good idea, but in my experience back when I freshly installed Samba on UCS it was usually just working. It is one of those older extensions so it has been tested quite much. (fingers crossed)

[1] https://github.com/univention/univention-corporate-server/tree/5.0-6/services/univention-s4-connector/ldap