Easy Active Directory integration with Likewise Open
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.
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
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).
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.
Buy this article as PDF
Powerful man-in-the-middle attack is now targeting online shopping.
Another high-profile coder says the kernel team needs a kinder, gentler culture.
Bug database has a bug of its own that could allow an intruder to create an unauthorized account.
Report focuses federal resources on achieving universal Internet access.
Leading browser makers say “no” to porous encryption algorithm
Report from the X-Force group says attackers are using TOR to hide their crimes
Future Firefox extensions will be compatible with Chrome.
Better read this if you bought your computer before 2011
Users should upgrade to the new version as soon as possible
Xen project announces a privilege escalation problem for Qemu host systems