UCS Usage, LDAP questions

Anyone whom can help -

I’m just starting with LDAP and UCS and we believe that UCS could take care of a number of issues for us. I apologize if these are very newbie questions (I’m sure they are - LOL!!), so please bear with me while I learn this.

Background: We are going to be working more with Google Apps and, in order to make this process easier, we’ve decided that we need an LDAP server outside of Active Directory 2008 R2 (where all of our users are - we are a very heavy Windows shop) that can sync with Google via GADS. To that end, we want to implement LDAP and also extend the basic user schema to add the fields that GADS are requiring from us that aren’t native in Active Directory. Additionally, we want to be able to have our users be able to log into a web interface and change their AD password whenever they need to. While we are a Windows-heavy shop, we are NOT an exclusively Windows shop - we’re getting more and more linux systems and Macs.

After setting up a UCS Core Edition server, we found that we immediately have the ‘change password via a web interface’ option available to us.

What I’m now looking into learning/understanding is the following:

  • How do I extend the schema of the users to be able to add some additional fields for GADS and, from that, learn how to add other fields down the road as we desire?
  • How can I query the LDAP information on the UCS server about our AD from another system using standard LDAP commands like ‘ldapsearch’?

Additionally, with what I am describing what we are doing above am I free (no pun intended) to use the UCS Core Edition? All I’m looking for is an ‘interface’ from our Active Directory system that can be queried and extended via LDAP, so I believe I am fine but I wanted to verify.

Thank you in advance for anyone whom can assist me. If anyone would like to reach out to me directly, please feel free at cbuege@moreycorp.com.



In UCS you can add LDAP schemas to the server by using the udm settings/ldapschema module.

However, before you do that I suggest you take a look at Univention’s extended attributes. Univention recognizes the need for user-controlled LDAP attributes and provides a set of 20 pre-defined LDAP attributes just for this case. The admin can configure each of those attributes to be accessible in the Univention Management Console (the web interface) and the Univention Directory Manager (the command-line management tool for the domain, udm). You can configure the name it is listed under and various other aspects.

In the LDAP those attributes are named »univentionFreeAttribute1« through »univentionFreeAttribute20«.

The schema for these custom attributes is always active, so you can start using them right away.

On a UCS system there are actually two LDAP servers running: one from the Samba 4 service (that’s the Active Directory portion of a UCS) and the OpenLDAP one. The OpenLDAP one listens on the port 7389.

So connecting to that server can be done with the usual commands:

ldapsearch -x -h hostname-of-the-ucs-master -p 7389 -D uid=…,cn=users,dc=… -b ldap-base-dn -W

You can look up your LDAP base DN with the command »ucr get ldap/base«. Note that the OpenLDAP is configured not to allow anonymous binds by default, meaning you have to use a bind DN with -D and provide the appropriate password. Often we create a single user for this purpose, e.g. called »ldapsearch« or something similar.

As far as I’ve understood their changes to the licensing: yes, you’re fine. The core edition is free to use however you want. Take this with a grain of salt, though, as I’m not a Univention employee.

Kind regards,

Moritz -

To say that your post answered my questions would be a VAST understatement. The information you gave me was spot-on perfect and answered my questions perfectly. Thank you very much!! Should you ever be in the Chicago area, I owe you a great dinner!

The only other question I have at this point is this: Is it possible to enable my users to administer any of their own information via the UCS web interface beyond password changes? I’m not sure what something like that would be called so I am not sure how to ask the question. Basically, we want them to be able to go to a web page, administer their own phone numbers, assistant’s information, employee numbers, etc. but NOT be able to change user names, etc. (stuff that would affect their AD information). Is there a way to enable edit rights for certain fields but not others?

I’ll go ahead and create a new post anyway to see if someone else has any quick ideas.

Thanks again!!



you’re quite welcome. Unfortunately I’m on the other side of the Atlantic, but I appreciate the thought :slight_smile:

About your other question: I’m not 100% certain but positive that you cannot grant permissions on such a level. Well, an LDAP server can via ACLs, but I don’t think there’s web frontend support for access to more than just the password.

You can assign multiple administrators by adding them to the appropriate groups, but then they’ll have access to the whole UCS management system, not just their own entry. You can restrict this kind of access to specific UCS modules, however, see section 4.8 of the admin manual. Using this for users is an »all or nothing« kind of affair, though; either a person has access to the users module (and therefore to all the users in the system) or not (no permission to edit users at all).

Speaking from OpenLDAP’s point of view: you can create ACLs that basically say »the user that’s currently logged in (bound to the LDAP server) can edit attributes X, Y and Z of his/her own LDAP object«. That’s how access to your own password field is implemented. What you would need on top of that is some kind of nice GUI/web app. I’m not aware of a simple one, but there are complex ones like phpLDAPAdmin, of course. Those might be overkill, but it depends on your use case and the technical expertise of the users you want to grant such access.

The administration manual’s section 3.4.5 has some more information about using ACLs within the UCS context.

Discussion on the OPs last question continues here: Enabling users to maintain some of their own fields