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:~$

Figure 5: The GDM display manager requests a login name on authentication. In this AD, the name consists of the domain name, EXAMPLE, a plus sign as a separator, and the username.

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.

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).

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).

Figure 6: Likewise implements a single sign-on through Kerberos. Users do not need to enter a password to log on.

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.