Comparison to a Windows Domain in Linux

gelgie

Ok, I've taken a few classes and done some UNIX/GNU Linux reading but have never seen this in any of my reading. I understand it at a local machine level, setting up users and groups with access to specific resources but never at a LAN/WAN level. Working in a completely Windows shop may have deluted my concepts as well.

What does Linux use for a multi-user Windows-domain-style set up (without a Windows domain)? I've seen a lot of 'server' versions of GNU Linux and distros but how do they authenticate in a multi-PC environment? Does GNU Linux offer the option to authenticate with a single server or 'domain controller' and then have access to multiple resources on the network? Where do you set up the users/groups?

Links are appreciated.

Comments

spaans Sun, 2006-10-29 01:32

I'd be interested in some help with this as well.
With Windows, I got used to the "Workgroup" idea of organizing a small number of computers together. In Linux is there a similar equivalent? Or do I have to go all the way up to Directory/Authentication services like LDAP or Kerberos?

I know Samba works well, but is that the ideal solution for <10 Linux-only computers?
Thanks!

john Mon, 2006-10-30 19:57

Linux and Unixes have had options for centralized authentication for quite a while.

It really is a multi-level problem that takes a few different packages to solve.

Centralized Authentication: This is the big one that people generally think of. The old and perhaps easier version of this is Network Information Services (NIS.) You can use NIS to provide centralized authentication by centralizing the passwd, group and shadow files. It supports lots of other databases too like hosts, services, protocols and more. If you only want to use NIS for authentication then you can leave these off. NIS has been replaced by LDAP, but if you wanted to work with it I'm sure it works fine for you.

LDAP is the now the common option for centralized authentication. It's a little more difficult to setup but it mirrors the functionality of Active Directory. For easy setup use the smbldap-tools utilites to convert passwd, group and shadow files to LDAP.

So far the options that I've mentioned are really for Linux clients. If you have Windows clients that you want to authenticate then Samba is what you want. It provides the same authentication functions as NT4 and works quite well with XP, but requires a simple Registry change. Samba has several password back-ends and can also use a Windows NT, XP, 2K3 server to authenticate against, essentially a member server.

We put a lot of Samba servers in and use LDAP as the back end so that the same user record authenticates for Samba (Windows workstations) and for other services as well.

Single Signon: This is a little different than centralized authentication. This is where one logs on once and has access to a wide range of servers without having to provide a password. The option for Linux is Kerberos. This isn't required.

Shared home directories: So now you've got lots of Linux boxes authenticating against a central server. You want to be able to access the same desktop and home directory on each workstation. This is where Automount Daemon (amd) comes in. AMD is dead simple to setup and auto-mounts and unmounts NFS shares. Generally you setup users to have home directory paths like /net/<servername>/home/<logname> and setup amd to moun on /net (this is the default) then you share /home on the server and that's it.

Shared home dirs has a similar problem as Windows. If you've got an icon on the desktop that requires a certain package to be installed it won't work unless you're on a workstation that has it installed.

For notebook computers we generally leave the home dir on the disk and backup or sync it when it's on the network. We also generally setup the user in the notebook's passwd too.

Collaboration directories: The user authentication is a little different for Linux file systems. In Windows you're used to having new files inherit the permissions of the parent folder. In Linux the permissions are based on the 'umask' value. The owner of the file is the user who created and the group membership of the file is the primary group of the user. This causes problems because a user may have a primary group of "manager" but will exchange files with users who won't be part of that group. This is solved using the setgid bit on a dir. Set the group of the directory to match the users who will access, let's say 'engineers'. Set users to have a umask of 007 in their profile, chmod 2770 the directory and chgrp engineer the directory. Now all files created have the group of 'engineer' and have rwx as the group permissions. Now any user the belongs to the engineer group can read and write the files.

This is a lot to cover, but it's all there. And Windows AD uses most of the same technologies.
--
John Van Ostrand
Net Direct Open Solutions

Bill Thu, 2006-11-09 21:45

> We put a lot of Samba servers in and use LDAP as the back end

Interesting. Presumably instead of Active Directory (= MS LDAP). The windows side isn't unhappy because of it? Any functionality lost?

Can you point the authentication direction for a more complicated example?

Suppose you have a directory of content, web, shared files, whatever.

You have 4 groups:
- admins / managers - can do anything they want to anything.
- contributors / editors - can modify their own groups, or perhaps all groups, read / write, but not manage / delete / change permissions, etc.
- readers - can read everything, but that's it.
- everyone else - no access at all.

Do your applications handle this, or are additional facilities needed?

<code>[color=#dcdc00]© B. Switzer - No copying or duplication in whole or in part permitted.[/color]</code>