PASSDB: local and domain accounts

Mayers, Philip J p.mayers at ic.ac.uk
Wed Nov 15 10:55:17 GMT 2000


Why not:

ssh -l "DOMAIN\user"
ssh -l "localuser"

So, we have the following:

1) Samba/Unix machine as a standalone server

a) We can have the accounts in /etc/passwd, passwd.so for Samba's usage
   This only works with plaintexts password. NOONE is going to use this, if
   only because they have to apply a registry patch.

b) We can have local accounts in /etc/passwd, "NTLM" accounts
   in TDB/LDAP/smbpasswd, using nss/pam_winbind to make them available
   as system accounts WITHOUT a "DOMAIN\" prefix as well. So, this would
work:

/etc/passwd:

root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:
daemon:x:2:2:daemon:/sbin:
adm:x:3:4:adm:/var/adm:
lp:x:4:7:lp:/var/spool/lpd:
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:
news:x:9:13:news:/var/spool/news:
uucp:x:10:14:uucp:/var/spool/uucp:
operator:x:11:0:operator:/root:
games:x:12:100:games:/usr/games:
gopher:x:13:30:gopher:/usr/lib/gopher-data:
ftp:x:14:50:FTP User:/var/ftp:
nobody:x:99:99:Nobody:/:

LDAP entries:

dn: uid=pjm3,ou=People,ou=Directory,dc=net,dc=ic,dc=ac,dc=uk
objectClass: top
objectClass: posixAccount
objectClass: shadowAccount
uid: pjm3
cn: pjm3
uidNumber: 26406
gidNumber: 6572
rid: 43562
homeDirectory: /home/cscmgb/cs/uss/pjm3
gecos: Mayers, Mr Philip
description: Mayers, Mr Philip
loginShell: /bin/bash
lmpassword: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
ntpassword: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

And use pam/nss_winbind, giving:

getent passwd

root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:
daemon:x:2:2:daemon:/sbin:
adm:x:3:4:adm:/var/adm:
lp:x:4:7:lp:/var/spool/lpd:
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:
news:x:9:13:news:/var/spool/news:
uucp:x:10:14:uucp:/var/spool/uucp:
operator:x:11:0:operator:/root:
games:x:12:100:games:/usr/games:
gopher:x:13:30:gopher:/usr/lib/gopher-data:
ftp:x:14:50:FTP User:/var/ftp:
nobody:x:99:99:Nobody:/:
pjm3:x:26406:6572:Mayers, Mr Philip:/home/cscmgb/cs/uss/pjm3:/bin/bash

So, it combines them. "NTLM" accounts can use encrypted passwords, local
/etc/passwd accounts can't, because there isn't a hash stored for them. This
would mean you couldn't access local accounts, pretty much.


2) Samba server as a domain member

Local accounts accesible without a prefix, domain accounts accessible with a
prefix, eg:

getent passwd

root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:
daemon:x:2:2:daemon:/sbin:
adm:x:3:4:adm:/var/adm:
lp:x:4:7:lp:/var/spool/lpd:
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:
news:x:9:13:news:/var/spool/news:
uucp:x:10:14:uucp:/var/spool/uucp:
operator:x:11:0:operator:/root:
games:x:12:100:games:/usr/games:
gopher:x:13:30:gopher:/usr/lib/gopher-data:
ftp:x:14:50:FTP User:/var/ftp:
nobody:x:99:99:Nobody:/:
pjm3:x:26406:6572:Mayers, Mr Philip:/home/cscmgb/cs/uss/pjm3:/bin/bash
IC\user:x:543663:3263:User, Mr A:/home/cscmgs/cs/uss/user:/bin/bash

NOTE: You need to be flexible in how winbind reformats the user. It would be
nice if the above could come out as:

pjm3:x:26406:6572:Mayers, Mr Philip:/home/cscmgb/cs/uss/pjm3:/bin/bash
user at IC.AC.UK:x:543663:3263:User, Mr A:/home/cscmgs/cs/uss/user:/bin/bash

Then various things (like kerberos cross-realm logins, etc) would work.

3) Samba as a PDC is the easy one. Local /etc/passwd accounts don't show up
at all in SMB. Domains account show up with a prefix.

Regards,
Phil

+----------------------------------+
| Phil Mayers, Network Support     |
| Centre for Computing Services    |
| Imperial College                 |
+----------------------------------+  

-----Original Message-----
From: Gerald Carter [mailto:gcarter at valinux.com]
Sent: 14 November 2000 18:07
To: samba-technical at samba.org
Subject: PASSDB: local and domain accounts


<snip

There is one minor problem.  Really it has not so much 
to with Samba as it does with winbindd and pam_winbind.
Consider the case where you would like to configure sshd
for authenticating against remote domain accounts.
This is only case when operating as a domain member
(not as a PDC).

In this case, winbindd will only check against domain
accounts.  However, I can envision cases where you would
want to validate against local Samba accounts as well.
There is currently no way to access these.

No you may be thinking to yourself, "but local 
Samba accounts already exist in /etc/passwd.  You can 
use those."  However, consider the unification of
passwords.  What if the Samba lanman/nt password is 
different than /etc/passwd?  Also consider the case 
of uid allocation upon demand for creating new local 
accounts in samba.  These would never exist in 
/etc/passwd.  Only as a uid in a Samba TDB.

This problem can be solved in one of two ways:

  1) make winbind check local accounts on the 
     samba server (via MS-RPC) as well as domain
     accounts on the PDC

or,

  2) develop as pam_passdb.so and nss_passdb.so 
     module. 

I like #2 better as it maintains the distinction 
of passdb handling local accounts and winnbindd 
handling remote accounts.

What is required to make all this work is an account 
management tool.  The following functions implemented
by the passdb API are used to actually update persistent
storage

	BOOL pdb_update_sam_account(SAM_ACCOUNT*);
	BOOL pdb_add_sam_account (SAM_ACCOUNT*);
	BOOL pdb_delete_sam_account (char* username);

If you want to add update capabilities to the passdb
(/etc/passwd for example), then you write these routines.
Currently the pdb_add_sam_account() call for smbpasswd
requires that the UNIX account already exist.  The 'add 
user script' is called before pdb_add_sam_account() is.  This 
should be moved below the API.  smbd should not have to 
worry about this.  By moving the 'add user script' to 
a lower layer, things like "smbpasswd -a <user>" will work
even if the UNIX account did not exist beforehand.


Make sense?  We can support user manager as tool.  If so,
the I really think that we should follow the rpcclient / 
samedit path as well.






-- Cheers, jerry
----------------------------------------------------------------------
   /\  Gerald (Jerry) Carter                     Professional Services
 \/    http://www.valinux.com  VA Linux Systems    gcarter at valinux.com
       http://www.samba.org       SAMBA Team           jerry at samba.org
       http://www.eng.auburn.edu/~cartegw

       "...a hundred billion castaways looking for a home."
                                - Sting "Message in a Bottle" ( 1979 )





More information about the samba-technical mailing list