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
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
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.
« Previous 1 2 3 4 Next »
Buy this article as PDF
(incl. VAT)