8.3. Logging into IdM
Users are authenticated to IdM services, including the command-line tools and the web UI, using Kerberos authentication. This means that logging into Identity Management requires running
kinit.
Running
kinit issues the user a Kerberos ticket. This ticket is checked by any IdM or Kerberos-aware service, so that a user only needs to log in once to access all domain services. Domain services include the IdM web UI, mounted file shares, wikis, or any other application which uses IdM as its identity/authentication store.
8.3.1. Logging into IdM
Logging into Identity Management requires running
kinit on a client within the IdM domain.
$ kinit
The
kinit command must be run from a machine which has been configured as a client within the IdM domain, so that the client authenticates with the IdM KDC.
Simply running
kinit logs into IdM as the currently logged-in user account. This user account must also be an IdM user for them to authenticate to the IdM Kerberos domain successfully. For example, if you are logged into the machine as user:
$ kinit Password for user@EXAMPLE.COM:
Note
If SSSD or
pam_krb5 is configured on the IdM client machine, then when a user logs into the machine, a ticket is created which can be used for machine services which require authentication, such as sudo.
8.3.2. Logging in When an IdM User Is Different Than the System User
A person's system user name is different from the IdM user name. To specify an IdM user name or to switch accounts, simply run the
kinit command again and specify the new user. For example:
$ kinit userName Password for userName@EXAMPLE.COM:
When the server is first set up, an administrative user,
admin, is created to perform normal administrative activities. To authenticate as the admin user, use the name admin when running kinit:
$ kinit admin
Note
Only one set of tickets can be stored per logged-in user. The current stored credentials are the ones that will be used when accessing IdM services.
If you were already connected to the IdM web UI as another user, refresh the browser to display the updated details for the new user.
8.3.3. Checking the Current Logged in User
Use the
klist command to verify the identity and the ticket granting ticket (TGT) from the server:
$ klist Ticket cache: FILE:/tmp/krb5cc_500 Default principal: ipaUser@EXAMPLE.COM Valid starting Expires Service principal 11/10/08 15:35:45 11/11/08 15:35:45 krbtgt/EXAMPLE.COM@EXAMPLE.COM Kerberos 4 ticket cache: /tmp/tkt500 klist: You have no tickets cached
It's important to know who the authenticated user is because the currently-authenticated user is the only one who can access the IdM services. The Kerberos client libraries for
kinit have some limitation, one of them being that the current ticket is overwritten with any new invocation of kinit. Authenticating as User A and then authenticating as User B overwrites User A's ticket.
To allow there to be multiple authenticated users on a machine, set the
KRB5CCNAME environment variable. This variable keeps credential caches separate in different shells.
8.3.4. Caching User Kerberos Tickets
Only one set of tickets can be stored per logged-in user. The current stored credentials are the ones that will be used when accessing IdM services.
For example, if you authenticated as
admin, added a new user, set the password, and then tried to authenticate as that user, the administrator's ticket is lost.
To keep separate credential caches in different shells, a special environment variable,
KRB5CCNAME, can be used.
