Single Sign-On and the Corporate Directory, Part III
With Samba v3.0.11, the notion of privileges was introduced. Prior to this version, a network-accessible uid 0 user was required for all user, group, machine and printer management. As of v3.0.11, a user with the proper privileges can initiate these types of requests. A uid 0 user is still necessary eventually for some of these, but it no longer need be network-accessible. So, you might be wondering why we added a uid 0 account to the directory. Well, there's a bit of a chicken-and-egg problem when initially setting up Samba. In order to perform these special operations, you need the proper privileges, but you can't grant yourself those privileges without having those privileges. So, to grant a normal user those privileges, you need the uid 0 user briefly, and then you can remove it from the directory. To find out which privileges your version supports, you can use the net command:
# net rpc rights list -U root Password: SeMachineAccountPrivilege Add machines to domain SePrintOperatorPrivilege Manage printers SeAddUsersPrivilege Add users and groups to the domain SeRemoteShutdownPrivilege Force shutdown from a remote system SeDiskOperatorPrivilege Manage disk shares
Newer versions have added more privileges so make sure you know all that your version supports before proceeding. Now we need to assign privileges to groups and/or users. The obvious first step is to grant all privileges to the Domain Admins group:
# net rpc rights grant "CI\Domain Admins" \ SeMachineAccountPrivilege SePrintOperatorPrivilege \ SeAddUsersPrivilege SeRemoteShutdownPrivilege \ SeDiskOperatorPrivilege -U root Password: Successfully granted rights.
At this stage, we should be able to remove the root user from the directory, because any member of the Domain Admins group should be able to issue administrative Samba commands.
So we have a Samba user but really nowhere for this user to login to. In the Windows world, machines must join the domain for user domain accounts to be valid. When a machine joins the domain, it needs to create a domain account for itself. This account looks exactly like a regular user account except that it ends with a dollar sign. Because I don't use the smbldap tools, I wrote a small Perl script that reads the admin dn's password from the secrets.tdb and adds the machine account to the LDAP directory. The script is available from the on-line Resources and depends on the Crypt::SmbHash, Net::LDAP, File::Temp and TDB_File Perl modules. Once you have this script in place, you can add the machine to the domain by right-clicking on My Computer, choosing Properties, choosing the Computer Name tab and then clicking on the Change... button. Enter an appropriate computer name if one isn't already provided, then choose the Domain: option in the Member of field and enter your Samba domain name (Figure 1). Once you click OK, it will ask you for a user name and password. Enter the user name and password for the user that is a member of the Domain Admins group—leggett, in my case. After a few moments, you should receive a message that welcomes you to the domain. Once you reboot, you'll have the chance to log in as a domain user.
Although it's fine that you now have Windows machines plugged in to your infrastructure, this article is also about single sign-on. You might ask ask yourself “But authentication isn't being served by Kerberos, so how will single sign-on work?” MIT has a Kerberos for Windows package that allows you to obtain and manage tickets similar to Apple's Kerberos.app (Figure 2).
The two main needs for single sign-on are SSH access and mail access. Certified Security Solutions has patched the PuTTY SSH client for Windows to allow GSSAPI authentication. In order to use the MIT Kerberos for Windows under Windows 2000 and XP systems, copy the file plugin_mitgss.dll to plugingss.dll in the PuTTY install directory. Once you fire up PuTTY, go to the Auth menu in the Connection/SSH category and check Attempt GSSAPI/Kerberos 5 authentication (Figure 3). Make sure you have valid Kerberos credentials, and away you go.
The last major piece to get working is mail access. Microsoft does not use GSSAPI as its authentication scheme. Instead it uses what is called SPNEGO. Because of this, Outlook and Outlook Express will not work with our single sign-on environment. But there's good news. Qualcomm's Eudora e-mail package supports GSSAPI, and it has a free version to boot.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
|Secure Server Deployments in Hostile Territory, Part II||Jul 29, 2015|
|Hacking a Safe with Bash||Jul 28, 2015|
|KDE Reveals Plasma Mobile||Jul 28, 2015|
|Huge Package Overhaul for Debian and Ubuntu||Jul 23, 2015|
|diff -u: What's New in Kernel Development||Jul 22, 2015|
|Shashlik - a Tasty New Android Simulator||Jul 21, 2015|
- Secure Server Deployments in Hostile Territory, Part II
- Hacking a Safe with Bash
- Huge Package Overhaul for Debian and Ubuntu
- KDE Reveals Plasma Mobile
- The Controversy Behind Canonical's Intellectual Property Policy
- Home Automation with Raspberry Pi
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- diff -u: What's New in Kernel Development
- General Relativity in Python