Easy Active Directory integration with Likewise Open

Verbose

The likewise-open package contains three diagnostics tools – lwinet, lwimsg, and lwiinfo – that are useful for debugging, among other things.

Because Likewise is based on the Samba Winbindd code, the tools will handle the tasks normally performed by the Samba Winbind daemon. By entering lwiinfo, you can check the connection to the domain controller.

The tool corresponds to wbinfo in the Samba suite. Both of these tools query the Winbind daemon. For example, lwiinfo -u lists all the domain users in the default domain:

EXAMPLE+mokr000
EXAMPLE+phkr000
EXAMPLE+wane000 [...]

The same principle applies to groups in the directory service, which are output by the -g option. This ensures that Linux knows the AD names. Entering lwiinfo -g lists the known groups:

EXAMPLE+accounts
EXAMPLE+marketing [...]

Again, Likewise uses the + character, configured in lwiauthd.conf, as the Winbind separator. The lwimsg tool corresponds to smbcontrol and is used to control Winbindd, setting the debug level, for example. The counterpart to the Samba net tool, which is used for remote administration of a domain, is lwinet.

After installing the software, it is a good idea to try logging on to AD. The user name format has to match the format defined for the directory service. For example, if you keep the default setting for domain and username separation, but change the separator to the plus sign, users will need to enter their names as DOMAIN+username when they log in at the console or with a desktop manager (see Figure 5):

ubuntu Login: EXAMPLE+wane000
Password:
EXAMPLE+wane000@ubuntu:~$

As mentioned before, Likewise authenticates users via the Kerberos protocol by requesting a TGT from the KDC before going on to install the ticket locally on the client as /tmp/krb5cc_UID (see Listing 2). The klist command displays a user's valid tickets.

A user who has a ticket can access kerberized services on the network without logging on separately with the network service.

Listing 2

klist Displays Local Tickets

01 $ klist
02 Ticket cache: FILE:/tmp/krb5cc_1560282197
03 Default principal: wane000@EXAMPLE.ORG
04
05 Valid starting     Expires            Service principal
06 08/12/08 13:48:08  08/12/08 23:48:08  krbtgt/EXAMPLE.ORG@EXAMPLE.ORG
07         renew until 08/19/08 13:48:08
08 08/12/08 13:48:08  08/12/08 23:48:08  SUSE$@EXAMPLE.ORG
09         renew until 08/19/08 13:48:08

Single Sign-on

To allow a network service to grant a user password-less access, the administrator has to assign a Service Principal Name (SPN) to the service. The name identifies the service within the AD environment. The service requests a service ticket for the Service Principal from the KDC, identifying itself with its TGT.

The SPN comprises a service definition, followed by a slash and the fully qualified hostname of the server, an at sign, and the domain.

Service definitions include host, ftp, or pop. If a user establishes an SSH connection to another Likwise-managed AD member computer, the kerberized service presents the user's TGT and requests a service ticket from the KDC for, say, the SPN host/ubuntu.example.org@EXAMPLE.ORG – this assumes that the local ticket cache does not already have a ticket. The service ticket contains the user ID of the requesting user and the session key. Likewise Open encrypts this with the server key and stores it in the user cache like the TGT (see Listing 3).

Listing 3

Tickets in the Credentials Cache

01 $ klist
02 Ticket cache: FILE:/tmp/krb5cc_1560282197
03 Default principal: wane000@EXAMPLE.ORG
04
05 Valid starting           Expires               Service principal
06 08/13/08 15:48:29        08/14/08 01:48:30     krbtgt/EXAMPLE.ORG@EXAMPLE.ORG
07           renew until    08/20/08 15:48:29
08 08/13/08 15:48:30        08/14/08 01:48:30     SUSE$@EXAMPLE.ORG
09           renew until    08/20/08 15:48:29
10 08/13/08 15:48:38        08/14/08 01:48:30     host/ubuntu.example.org@
11           renew until    08/20/08 15:48:29
12 08/13/08 15:48:38        08/14/08 01:48:30     host/ubuntu.example.org@EXAMPLE.ORG
13           renew until    08/20/08 15:48:29

The SSH client automatically sends the encrypted service ticket and an encrypted timestamp to validate the authenticator's sshd. This guarantees that each ticket request is unique, while ensuring that the client really does possess the session key. Without the authenticator, it would be easier for an attacker to sniff a ticket off the network traffic and launch a replay attack.

The server validates the service ticket presented to it. To to so, it refers to the local keytab file, /etc/krb5.keytab. The file stores the server key, which the server uses to decrypt the service ticket, thus revealing the session key. The authenticator is based on the session key; if it succeeds, the user is authenticated without a password (Figure 6).

Establishing a Connection

Likewise Open automatically configures existing SSH clients and clients on joining the domain, allowing them to use Kerberos to authenticate in the future. Server-side, Likewise adds the lines

GSSAPIAuthentication yes
GSSAPICleanupCredentials yes

to the /etc/ssh/sshd_config configuration file. Likewise also adds the following lines for an SSH client:

GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

The GSSAPIDelegateCredentials instruction passes the TGT to the target server. For all other settings, the software uses the Generic Security Services API (GSSAPI), a generic interface for security services such as Kerberos.

Read full article as PDF:

Likewise.pdf (744.28 kB)

Related content

comments powered by Disqus

Direct Download

Read full article as PDF:

Likewise.pdf (744.28 kB)

News