Xcalar uses LDAP to interact with AD. For Xcalar, AD provides three things:
1. a way to verify usernames and passwords,
2. a way to get the user's name (used on the desktop) and e-mail address (used in messages to Xcalar support),
3. a way to test if an AD user can use Xcalar, and if an AD user is a Xcalar administrator.
LDAP configuration is a little different than other, more modern Internet protocols, so
it can seem a little daunting. An LDAP is just a database much like a SQL database,
except the data is laid out like a tree instead of tables in a schema. Xcalar wants to
search that database to get just one AD user record when a login is successful.
So how does it do that?
First, Xcalar needs to know where the AD instance is. It uses an URI much like a web
Here, the protocol is ldap, the AD server host name is server.mycompany.com, and the TCP
port is 389 (the LDAP standard.)
Once Xcalar knows where the AD server, it sends the username and password to the AD LDAP
interface to log in. With LDAP, this process is known as binding. An LDAP bind operation will
only succeed if the username and password match those on file for an AD user.
Next, Xcalar needs to know where to look inside the LDAP that AD provides. The root
of the LDAP tree is based on the name of the windows domain. So if the AD domain is
mycompany.com, this is the root of the LDAP tree:
Xcalar automatically searches everything in the tree below the LDAP root for user records.
Next, Xcalar needs to understand what that makes for a matching user record. AD LDAP
trees contain a lot of information, about hosts, about printers, about groups. Xcalar issues
the search command to the LDAP with a filter attached to it. A common filter used with
AD instances looks like this:
This filter says that the right user record has an AD LDAP objectlcass of user, and has the
the userPrincipalName (the username) matching a Xcalar LDAP connector macro named
%username% (which is what the user typed on the screen).
If Xcalar finds a record in the tree that matches this filter, it then pulls the e-mail address and
user's first name out of the record.
Finally, the record returned by AD has one other field of interest to Xcalar: memberOf. This is
the list of all groups that the user belongs to. Xcalar needs to agree with AD about the identity
of two groups:
1. a group to which all Xcalar users belong, and
2. a group to which all Xcalar admins belong (a subset of the user group.)
These two groups can be the same group, if all users are allowed to be admins.
So, the Xcalar LDAP/AD connector checks to see if the user belongs to the "user group". If the
user does not, then authentication fails. If the user does, then admin group membership is checked.
If the user belongs to that group, the user is logged into Xcalar as an admin. Otherwise, the user
connects to Xcalar as a regular user.