Configuring Fusion UI LDAP security for Active Directory

Configuring Fusion LDAP security for Active Directory

Published on July 28th 2015, by Gerald Kanapathy

Fusion LDAP configuration is very flexible and very powerful. This also means it can be confusing to get it right.

A very common case for configuring LDAP is for use with Active Directory. This is an example that should be pretty close to what customers need to configure.

There will be differences if customers organize their users and groups into different containers, or need to limit what users and groups are linked to Fusion. In that case, by understanding AD and LDAP queries, you can modify the below. But a basic standard config for AD looks like:

  • Realm name: corpdomain.company.com Whatever you want, but I'd say that the AD domain name would be a good choice, either fully-qualified or not.
  • Realm type: LDAP, obviously

  • Default Roles: Up to you, but probably should be minimal. (Note that you could actually create a whole realm just for admins, and point it to the same AD server as a "user" realm, but with different configuration. Some customers might like that control, but that's a different issue.)

  • Host: corpdomain.company.com The LDAP server host or IP. Note that in many environments that use AD, the fully-qualified AD domain name (e.g. corpdomain.company.com) will resolve via DNS to an AD domain controller, and will even automatically failover, since AD manages DNS itself.

  • Port: 389/636/3268/3269 389 is default, but in many places you must use SSL to use password authentication, so you should also try 636 with SSL enabled. Additionally, if you have a forest of AD domains, and you have groups and users over multiple domains in the forest, you may instead want to connect to the AD Global Catalog port. This is just another LDAP port, but runs on port 3268 or 3269 (SSL)
  • SSL?: Yes/No. See above, default ports for LDAPS are 636 (LDAP) and 3269 (AD Global Catalog)

  • Super User Bind DN: CN=userlogin,CN=Users,DC=corpdomain,DC=company,DC=com This doesn't actually have to be a "super" user, it just needs to be a user who can query LDAP/AD for users and group memberships. By default in most AD environments any AD user has permission to do this. Thus instead of "super" user, this really can be done by any old user account. Usually it will look like

  • Super User Password: Duh

  • Bind method: "Search". In AD, you usually have to use the "search" method. This is because our "bind" (i.e., log in with an ID) method assumes that the user login name is part of the user DN (Distinguished Name) in LDAP. This is sometimes the case in AD, but more often than not, the user login name is not in the DN. Thus, you instead have to "search" for the correct DN for the user to log in.

  • Search-based login: Base DN: CN=Users,DC=corpdomain,DC=company,DC=com The base DN of the container where user account objects are. This can be wide, usually just the base of the AD object tree will be fine.

  • Search-based login: Filter template: (&(sAMAccountName={})(objectCategory=Person)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))This is pretty powerful and can be configured to handle a lot of special cases. But a basic default would look something like this query. It looks for the account with the name that user logs in with ({}). It further filters by only finding users (in case workstations or computers have the same name), and excludes accounts that are disabled. (The weird query is just how AD works, don't question it.)

  • Group search: Group base DN: CN=Groups,DC=corpdomain,DC=company,DC=com See comments about user base DN, it might be different for groups, it might not.

  • Group search: Name attribute: CN You want to use the CN in all probability for groups.
  • Group search: Filter template: (&(member:1.2.840.113556.1.4.1941:={})(objectCategory=Group)) This weird query handles nested groups in AD. Not very many people use nested groups, so most of the time you're fine just using (&(member={})(objectCategory=Group))
  • Group Mapping: You must provide at least one if you're specifying the group search and filter, but it can actually be dummy values. The Group name is the value that is in the CN attribute (assuming you configured CN as the "Name attribute"). The role name is the Fusion role name.

Note BTW that I used objectCategory rather than objectClass in queries. This results in very possibly slightly faster performance

Have more questions? Submit a request

0 Comments

Please sign in to leave a comment.
Powered by Zendesk