4.1 - Authenticate with Studio¶
We will explain how to use the kerberos server to authentify users on a LDAP server. Let's first define the way we will store data in the LDAP server
We first have to configure the LDAP and Kerberos server, in order to be able to use the kerberos server to authenticate on the ldap server.
If you have installed the ApacheDS package, the simplest way is to start the server, and to connect on it using Studio, using the uid=admin,ou=system user with secret as a password (this password will have to be changed later !).
Once connected, right click on the connection :
On the Overview tab, check the Enable Kerberos Server box :
LDAP Server configuration¶
There are a few parameters that are to be set in the LDAP configuration :
* The SASL host must be the local server name (here, example.net) * The SASL principal is ldap/example.net@EXAMPLE.COM * The Search Base DN should point to the place under which we store users and services (dc=security,dc=example,dc=com)
Here is a snapshot of this configuration :
Kerberos Server configuration¶
Now, you can switch to the Kerberos tab, where some more configuration must be set :
* The Primary KDC Realm is EXAMPLE.COM * The Search Base DN is the same as for the LDAP server : dc=security,dc=example,dc=com
Here is a Ssnapshot of this configuration :
Once those modifications have been done, you must restart the server.
There is one more thing that you need to configure : your domain name (here, example.net_) has to be reachable on your machine. Either you define in on a DNS server, or you can also add it in your /etc/hosts file.
Here is a way to add it on a local host :
... 127.0.0.1 localhost example.net ...
We will distinguish between users and services : Users are human beings, or applications that can log on a service Services are applications on which a user can log in
In our case, the ldap server and the TGS are services.
Each user and each service will be declared using an entry in the ldap server.
We will store those entries in a part of the DIT where the kerberos server and the ldap server will be able to find them. Assuming we have created our own partition named dc=example,dc=com, we will define this hierarchy starting from there :
This can be injected in the LDAP server using this LDIF :
dn: dc=security,dc=example,dc=com objectClass: top objectClass: domain dc: security dn: ou=services,dc=security,dc=example,dc=com objectClass: top objectClass: organizationalUnit ou: services dn: ou=users,dc=security,dc=example,dc=com objectClass: top objectClass: organizationalUnit ou: users
Users and Service declaration¶
Now that we have built our container for users and services, we have to declare the users and services so that they can be used through kerberos.
Each user must have the krb5KDCEntry objectclass, and the userPassword attributeType (which is present in one of the following objectclasses : dmd, domain, organization, organizationalUnit, person, posixAccount, posixGroup and shadowAccount, or one of their inheriting objectclass. You can also add it to your own objectclass).
Our users will be organizationalPerson, which inherits from person.
For our sample test, here is a person we will inject in the LDAP server :
dn: uid=hnelson,ou=users,dc=security,dc=example,dc=com objectClass: top objectClass: krb5KDCEntry objectClass: inetOrgPerson objectClass: krb5Principal objectClass: person objectClass: organizationalPerson cn: Horatio Nelson krb5KeyVersionNumber: 1 krb5PrincipalName: hnelson@EXAMPLE.COM sn: Nelson uid: hnelson userPassword: secret
This user does not have a password yet.
Once the user has been injected, we can see that the server has created some krb5Key attributes :
dn: uid=hnelson,ou=users,dc=security,dc=example,dc=com objectClass: top objectClass: krb5KDCEntry objectClass: inetOrgPerson objectClass: krb5Principal objectClass: person objectClass: organizationalPerson cn: Horatio Nelson krb5KeyVersionNumber: 0 krb5PrincipalName: hnelson@EXAMPLE.COM sn: Nelson krb5Key:: MBGgAwIBA6EKBAj0pxNkimHOWw== krb5Key:: MBmgAwIBEaESBBCtIUs4tp38yqzxXzRtQXuQ krb5Key:: MCGgAwIBEKEaBBhXB84pUpIsHIy/Q8I9j4xenoz3XT5KXiU= krb5Key:: MBmgAwIBF6ESBBCHjYAUYGzaKWd6RO+hNT/H uid: hnelson userPassword:: e1NTSEF9VnhjYUl4U3JxUnAraWh1dXo2NEhzN1EwbXE0ZHBBQTNsUHJXMGc9P Q==
Those keys have been computed automatically by the Kerberos server. Every time you will change the password, the keys will be updated.
We can add as many users as we want, but keep in mind that the login name should be the first part of the krb5PrincipalName attributeType.
We now have to declare some services : the krbtgt service, which delivers tickets, and the ldap service.
A user (or a service) which will try to authenticate on the LDAP server will first get a ticket from the krbtgt service, then will access the ldap service with the provided ticket.
It's pretty much the same operation than for the user : create the entry, define a krb5PrincipalName, create a userPassword and inject the entry into the LDAP server.
Here is the associated LDIF file :
dn: uid=ldap,ou=services,dc=security,dc=example,dc=com objectClass: top objectClass: organizationalUnit objectClass: krb5KDCEntry objectClass: uidObject objectClass: krb5Principal krb5KeyVersionNumber: 0 krb5PrincipalName: ldap/example.net@EXAMPLE.COM uid: ldap userPassword: randomKey ou: TGT dn: uid=krbtgt,ou=services,dc=security,dc=example,dc=com objectClass: top objectClass: organizationalUnit objectClass: krb5KDCEntry objectClass: uidObject objectClass: krb5Principal krb5KeyVersionNumber: 0 krb5PrincipalName: krbtgt/EXAMPLE.COM@EXAMPLE.COM uid: krbtgt userPassword:: randomkey ou: LDAP
- - the userPassword is 'randomkey'. The key will not be generated based on a know password, they will use a random key.
- - the krb5PrincipalName has one more information, after the / character : EXAMPLE.COM for the krbtgt service, and example.net for the ldap service. For the krbtgt principal, the instance is always the realm name. For the ldap principal, the instance is the hostname, in lowercase.
- - the krb5KeyVersionNumber is 0
Again, once those entries have been injected in the LDAP server, the krb5Key attributeTypes will be created
Login using Studio¶
Now that the server is set, and the services and users are stored into it, we can create a new connection using the Kerberos authentication for the created users.
Create a new connection¶
On the "Connections" tab, right click and select 'New Connection...'
You will now have to set the network parameters, as in the following popup. Typically, set :
* The connection name (here, Kerberos User) * The LDAP server host (example.net) * The LDAP server port (10389) * The Provider (pick Apache Directory LDAP Client API)
You can check the connection on cliking the 'check network connection' button, you should get back a popup stating that the connection was established successfully.
Here is the screenshot :
Then click on Next to setup the authentication part. Select the following parameters and values :
* Authentication method : GSSAPI * Bind DN : the user name (here, hnelson) * Bind password : here, secret * Do not change anything in the SASL settings * Kerberos settings * Obtain TGT from KDC * Use following configuration : * Kerberos Realm : EXAMPLE.COM * KDC Host : example.net * KDC port : 60088
Here is the resulting screen :
Clinking in the 'Check Authentication' button should be succesfull.