Conjur provides an LDAPS interface which you can use to search, authenticate, and authorize users. You can also list groups and group members.
There are two primary use cases for Conjur LDAP:
- Authenticating and authorizing users for SSH.
- Authenticating and authorizing users to a client system such as OpenVPN or Jenkins.
Both use cases are addressed in a similar way, using the Conjur LDAP service.
Conjur uses the LDAPS protocol, running on the standard port 636. The connection is secured using
the standard SSL certificate. The path to the certificate can be found in the Conjur configuration
account: demo plugins:  appliance_url: https://conjur/api cert_file: /home/demo/conjur-demo.pem <-- Conjur certificate
To use the
ldapsearch tool, you can configure your ldap.conf to use the
Conjur LDAPS endpoint and to establish SSL trust. In the example below,
my-conjur-host is the host portion
of your Conjur appliance url.
# # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. URI ldaps://my-conjur-host TLS_REQCERT demand TLS_CACERT /path/to/conjur/certificate.pem
With this configuration in place, you can use
ldapsearch to test and interact with
Conjur LDAP from the command line.
Conjur LDAP can be used to control access to a resource, such as a VPN or Jenkins server. We represent the
resource as a Conjur Host asset. To bind to the ldap server you will need either
a host's credentials, or those of an owner of the host. Because Conjur does not allow permission checks on roles that
you don't have, the host role must belong to the users you want to allow to access it, or these users must have a permission
update) on the host resource.
Every distinguished name (DN) in Conjur LDAP has some common required elements:
- host=<host-id> The identifier of a Host
- account=<acct> Your Conjur organization account name
- o=conjur (required)
Suppose that the id of the host resource you are using is
vpn1, and your conjur account
my-company. The bind DN will be
To search for users, the base DN should be
and for groups it should be
Suppose you're username is
alice, and you have permission to
execute the ldap host,
whose id is
vpn1, and the conjur account is
my-company. The bind DN will be
The search base DNs for users and groups are the same as those used when you are bound as a host.
Every DN contains a Host id because Conjur LDAP searches are always performed in the context of a Host. The Host id in the DN defines a filter which governs all the LDAP results:
- the only User records returned are those which have
updatepermission on the Host and have an assigned UID number;
- the only Group records returned are those Groups which the Host is a member of and have an assigned GID number.
Suppose your Conjur system contains the following data:
group:developers - user:alice - user:bob group:contractors - user:charles host:jenkins-master host:gis-processing host:openvpn
And the following permissions:
group:developers can update host:jenkins-master group:contractors can execute host:gis-processing group:developers can execute host:openvpn group:contractors can execute host:openvpn
Then, each Host (
openvpn) can be used in a DN to:
- Authenticate and authorize a specific list of users, via LDAP
bind, who have access to that Host.
- Provide a specific list of users, via LDAP
search, who have access to that Host.
In this example:
bobwill be able to bind to the
openvpnDNs. They will also be listed as LDAP search results for these DNs. Their bind DNs would look like this:
charleswill be able to bind to the
openvpnDNs. He will also be listed as LDAP search results for these DNs. His bind DNs will be similar to the examples given above.
To add a User to LDAP for a Host, grant
update on the Host to the User, or add
the User to a Group which already has this privilege.
You can use the permitted_roles function to determine which users have access to a Host. For example:
$ conjur resource permitted_roles host:ec2/i-bcc223c1 execute [ ... ] $ conjur resource permitted_roles host:ec2/i-bcc223c1 update [ ... ]
$ ldapsearch -H ldaps://conjur \ -D uid=ec2/i-bcc223c1,ou=host,host=ec2/i-bcc223c1,account=demo,o=conjur \ -w 2kzfrz938swy8akqe78e2cmsffv20swwvx3hq66a317ymdj2103awyg \ -b "ou=user,host=ec2/i-bcc223c1,account=demo,o=conjur" # extended LDIF # # LDAPv3 # base <ou=user,host=ec2/bcc223c1,account=demo,o=conjur> with scope subtree # filter: (objectclass=*) # requesting: ALL # # alice, user, ec2/i-bcc223c1, dev, conjur dn: uid=alice,ou=user,host=ec2/i-bcc223c1,account=demo,o=conjur loginShell: /bin/bash cn: alice gidNumber: 5000 uidNumber: 1138 objectClass: posixAccount homeDirectory: /home/alice uid: alice # kgilpin, user, ec2/i-bcc223c1, dev, conjur dn: uid=kgilpin,ou=user,host=ec2/i-bcc223c1,account=demo,o=conjur loginShell: /bin/bash cn: kgilpin gidNumber: 50000 uidNumber: 1101 objectClass: posixAccount homeDirectory: /home/kgilpin uid: kgilpin # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2
$ ldapsearch -H ldaps://conjur -b "ou=group,host=ldaptest,account=sandbox,o=conjur" -D "uid=ldaptest,ou=host,host=ldaptest,account=sandbox,o=conjur" -w 2pr65jt2kbj3jh1q8nqyz3czzwhb5n7p2rhc3dh # extended LDIF # # LDAPv3 # base <ou=group,host=ldaptest,account=sandbox,o=conjur> with scope subtree # filter: (objectclass=*) # requesting: ALL # # ldapgroup, group, ldaptest, sandbox, conjur dn: cn=ldapgroup, ou=group, host=ldaptest, account=sandbox, o=conjur cn: ldapgroup gidNumber: 31336 objectClass: posixGroup memberUid: alice # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1
$ ldapsearch -H ldaps://conjur \ -D uid=alice,ou=user,host=openvpn,account=demo,o=conjur \ -w $password
The bind will be successful if:
- The bind password
-wis the user's valid password or API key.
- The user specified in the bind DN
updateprivilege on the host