NTDOM: SAMBA: NT 3.51 / 4.0 Domains for UNIX.

[Luke Kenneth Casson Leighton]

controlled copy: http://mailhost.cb1.com/~lkcl/ntdom-unix.txt. 

this message is going cc and bcc to what i hope can be considered some
appropriate digests and newsgroups, for various portions of this message.

contents:
---------

- dce/rpc in NT (not Win95)
- nt domain logins
- nt and unix administration
- nt to unix mapping
- sustaining current development
- short term plans
- long term plans
- strategic aim

summary:
--------

nt domain logins, and some experimental administrative capabilities, have
been added to an experimental development branch of samba, the publicly
available file/print share program that makes unix servers look like
microsoft windows.

further work is needed, but the goal is to make unix look like windows nt,
over a network.  this will include full unix command-line administrative
capability as well.

the implications of this are that unix will be fully adminsterable by the
standard nt server tools (e.g "user manager for domains"; "server manager
for domains"), and both unix and nt will be fully administerable using
HTML (cgi-bin wrappers around the smbclient program).

some of this functionality (both client and server) is already available,
in the cvs-tagged BRANCH_NTDOM version of samba.  this can be obtained by
following the instructions in http://samba.anu.edu/au/cvs.html, using the
above mentioned cvs tag.

this work is of sufficient importance (at least until and even when NT 5.0
becomes established) that i would like to continue with it. to finance
this, if anyone wishes to either sub-license relevant portions of the
current or future versions of the dce/rpc code for their own products, or
wishes to ensure that i can continue to research this project for at least
the next six months, please contact me. 

at present, samba and smbclient can only provide or obtain information
using dce/rpc: no capability has been added to administer domain servers. 
this can (should) only be possible to do by administrators.  adding or
changing SAM user accounts or domain groups is encrypted.  the "backup
domain controller" and "inter-domain trust relationships" also needs to be
researched. 

final point: anyone running windows nt who allows SMB access through their
firewall (ports 137-139) is strongly advised to look up and enable the
"RestrictAnonymous"  registry key in the microsoft KB articles, and to
look for information on the "red button" bug in NT.




dce/rpc in nt (not Win95)
-------------------------

nt runs an implementation of dce/rpc over an SMB inter-process
communication pipe.  it uses IDL to describe the data structures of the
various remote procedure calls.  IDL is also used in corba, i am led to
believe.

nt opens named pipes such as \PIPE\NETLOGON and \PIPE\ntlsa (to do NT
domain logins); \PIPE\samr (to do SAM database replication and
administration - e.g using SRVMGR.EXE and USRMGR.EXE); \PIPE\srvsvc (to
check on the status of files / connections / shares, and to disconnect
users or close files).

basically, all of the administration tools that can select "domains" or
"workstations" in nt server all use dce/rpc.

Windows 95 does _not_ use dce/rpc.  there are equivalent calls made to SMB
servers on the SMB Trans2 pipe, for some of the functionality needed by
Windows 95 (and Wfwg).  Windows NT does not use the majority of these
functions.  only occasionally, if a dce/rpc call is not implemented, will
an nt server or nt workstation "thunk" down to using SMB Trans2 calls.

the only attempts seen by Windows 95 to even remotely use dce/rpc is
simply to open \PIPE\srvsvc (or \PIPE\wkssvc) and then close it.  this
would appear to be a method to check whether a machine is, to all network
intents and purposes, an NT server or NT workstation (from an SMB file
access point of view, a Windows SMB client reacts differently depending on
what it determines the server to be.  the "determination" step is
extraordinarily convoluted, and is a really good example of bad object
orientated programming).

the dce/rpc over-the-wire data is relatively simple to decode. 
unfortunately, no-one except microsoft knows what's being used: you can
only infer the meaning of this data from clicking on various admin tools,
and seeing what happens. 

the work in progress is a double-edged sword for microsoft. their
proprietary system is being understood and implemented in a popular SMB
client / server suite for unix (samba).  one of the medium to long term
benefits to microsoft is that bugs will (and are) being found in their
code.  this can only improve the reliability and security of a quite
impressive implementation of remote server administration.

that this is the most widely used remote administration suite in the world
(USRMGR.EXE and SRVMGR.EXE, amongst other tools) makes it all the more
important that it be secure and reliable.


nt domain logins
----------------

these are documented in http://mailhost.cb1.com/~lkcl/cifsntdomain.txt,
and implemented in the BRANCH_NTDOM experimental version of samba.  samba
is available under the GPL.  anyone wishing to look at the appropriate
sections of the code under an exclusive non-GPL license is welcome to
contact me.

nt domain logons are what happens on nt when you press ctrl-alt-delete,
type in a username and password, select an nt-domain, and press return. 
what happens under Win95 is completely different (it uses the SMBtrans2
NetUserGetInfo call, but has the same end result.

a user profile is obtained from the nt domain login server (there are also
steps to determine what your domain login server is).  each and every
important step is verified with a client-server signature chain.  i am not
actually interested in the security of each of the signature chain: i just
want to see them implemented, for unix <-> nt interoperability purposes. 


nt and unix administration
--------------------------

the dce/rpc commands, once understood and implemented, can be used to
administer or be administered by, anything that also uses those commands. 
to the best of my knowledge, currently, only NT and its various ports to
unix (by AT&T and SCO) use these commands.  and samba. 

stub functionality has been implemented in the samba server code to enable
"user manager for domains" (USRMGR.EXE) to view unix user accounts, and
"server manager for domains" (SRVMGR.EXE) to view files, shares and
sessions on a unix server.

smbclient has been updated to allow it to send dce/rpc commands.  it can
be used, usually only with administrator priveleges, to provide exactly
the same information as USRMGR.EXE and SRVMGR.EXE.  this includes viewing
files, shares, sessions, domain users, domain groups and domain aliases. 
future versions will provide exactly the same administrative capabilities
as these two programs, and more.

by ensuring that smbclient's output is in a machine-readable format,
parsing scripts running from cgi-bins can be written that will allow NT
(and unix servers running samba) to be administered by HTML (web) clients.

[small side-note: the original purpose behind writing smbclient was as a
"boot-strap", or "testing" tool for smbd...]


nt to unix mapping
------------------

this area is probably going to cause the most pain to administrators of
mixed unix / nt systems, even though it's a pain at the moment.  there are
two areas of contention: users, and workstations.  users, because NT
supports, across all installations, unique (world-wide) user and
workstation identification.  the identification is subdivided into SIDs
(security ids) for a domain, and RIDs (relative ids - relative to the SID,
that is).  a RID can be either a local user or a local group.  regardless,
it must be unique within the domain (relative to the SID). 

NT also has some common (well-known) RIDs and SIDs that have specific
meanings (0x1f4 for the domain administrator's RID; S-1-1 for the World
SID: see winnt.h or cifsntdomain.txt for some details).

the various unix flavours use 0x0 for the uid of the root superuser. 
they do not support the concept of a well-known guest account, like NT
does: they certainly don't support, as standard, the concept of a "SID".

probably the easiest way to deal with this is to first convert to using
NIS+ (or an equivalent).  the reason for this is that both NIS+ and NT
support, in some form, the concept of "workstations" as individual users.
each domain must have a SID associated with it, and each user (including
workstations) must have a user id.  there are two other kinds of accounts,
which are used for inter-domain trust relationships, and for primary /
backup domain controller relationships.

SIDs and the well-known RIDs will need to be added to unix, somehow, in
order to support NT domains.  the NT posix sub-system simply adds 1,000 to
the unix uid to make a RID.  hopefully, it maps root to the well-known
administrator RID, and it is not known what happens to unix group ids.

it actually doesn't matter what the scheme is, as long as it exists,
whereby a set of unix accounts, workstations and unix groups are uniquely
mapped into a SID/RID pair, making them world-wide unique.

a _suggested_ scheme (with 16 bit unix ids) would be to use the NT posix
method for user ids (add 1,000 except for root) and to add 0x2000) to unix
group ids.

of even more contention at present is the issue of mapping existing NT
accounts into unix ones.  this would be best resolved by having a separate
SID for the unix domain, and setting up an inter-domain trust relationship
with the NT server.

[big but relevant side-note:

this only applies, by the way, to SMB access by NT workstations (files,
printers, domain logins): it does not apply to telnet, ftp or other
standard unix access to standard unix machines, unless the unix operating
system itself has been modified to use the SMB password mechanism.

this has been done with Kerberos, although this is only one specific
example:  complete replacements for daemons have in some instances been
written.  in other sites, functions with the same names and purpose of the
NIS system calls have been written, but they use kerberos instead of NIS
(it probably involved a recompile of the daemons that use the NIS system
calls, implying that a full source code license for that O/S was available
to that site). 

another example of this is to write / adopt pam_smb-0.6, a plug-in
authentication module.  please remember that this PAM has been released
under the Gnu Public License).

basically, if you can add Kerberos to your O/S, why not add NT domain
client capability, too.  and if you use PAMs or an equivalent, then you've
done most of the work and made it possible to expand to other
authentication systems in the future, without all the hassle...

end of big side-note].

samba supports NT encrypted passwords through the use of a file called
"smbpasswd".  if the NT user gives a correct NT password (fully documented
in cifs6.txt), samba allows the user access.  the unix password is not
involved in this process, and the unix password database still has to be
maintained if the users are to be allowed access to the standard unix
resources.

an alternative scheme to resolve the unix / nt username issue is to have a
unique mapping for domain RIDs for users within a unix domain, but to have
a non-monotonic mapping between those RID and the unix uids.  for example: 

NT user       / NT rid    Unix user  / uid
administrator / 0x1f4     root       / 0
root          / 0x1000    root       / 0
sales_usr1    / 0x1001    salesusr   / 521
sales_usr2    / 0x1002    salesusr   / 521 
foouser       / 0x1003    foouser    / 522
faruser       / 0x1004    faruser    / 523

each nt username / nt rid is unique, yet the sales_usr 1 and 2 map to the
same unix user and uid.  likewise with root and administrator.  this would
be implemented by having a database which is maintained in parallel with
the unix password file, which provides you with the mapping between unix
uids and nt RIDs.

a similar thing to usernames also needs to be considered for unix groups. 


sustaining current development
------------------------------

i'll not be ashamed of asking this: it incurs responsibility, which i accept. 

if sufficient people are interested that i continue this work, then please
contact me.  if i have misjudged the importance of this work or asked in
an inappropriate way / time, then it doesn't matter: i can always find
alternative work.  other people will, over a period of time, continue this
research and development.

i'm quite happy to write papers, go to conferences, provide companies with
exclusive rights to information or code for a negotiable amount of time. 
but not for free, any more: i will lose my house.

oh, one important thing that needs to be said: if anyone is _unhappy_ that
i (specifically) continue with this work or in this field, please say so. 
the last thing i want to happen is to annoy anyone to any significant
extent.  please bear in mind that this work has already begun.


short-term plans
----------------

- to research the "user manager for domains" functionality, finishing of
the "read-only" side.  this will allow viewing of unix users and groups
with USRMGR.EXE or smbclient.  at present, the user profile information is
available through smbd, but the domain group and domain alias information
is either stub-code or incomplete. 

- to research the "server manager for domains" functionality, again
finishing off the "read-only" side.  this will allow SRVMGR.EXE or
smbclient to view open files, sessions, shares and users on the server. 
the dce/rpc side of this has been implemented in samba.  smbd currently
only provides stub information; smbclient fully implements the client
side.  there are two buttons missing: "replication" and "alerts".  these
are on two separate dce/rpc pipes, which i have not yet examined, and
intend to. 

- to publicly encourage the discussion and resolution of the unix <-> nt
SID and RID issue, and to implement an example mapping in samba.

- to rework the dce/rpc code currently written so that it can be used in a
general way, not just in a samba-specific way (use of higher order -
sometimes known as callback - functions where appropriate, for some of the
enumeration containers.  e.g the "NetrFileEnum" and "SamrQueryDisplayInfo" 
functions).

- to write a PAM (plug-in authentication module) which will allow users of
Solaris 2.5 and Linux (the only systems that support PAMs, at the moment,
to the best of my knowledge) to log in to (and out of!) NT Domains.


long-term plans
---------------

to document the full set of dce/rpc administrative capabilities currently
available in nt server, and to see them implemented in samba (client and
server) as a means to test and prove their useability and worth (making
unix, from a network point of view, exactly like windows nt 3.51 / 4.0
server).

this will include:

- domain "primary / backup" relationships and inter-domain relationships

- adding / creating accounts (first implementation to be SAM accounts)

- closing of files / disconnecting of users / adding or removing shares.

once this has been achieved, to then suggest the possibility of extending
these calls for unix-specific (or other o/s, e.g MacOS) needs, as has been
done with the CIFS file access protocol (cifs-unix by SCO - www.sco.com; 
mac extensions by Thursby - www.thursby.com).

because the work already done by microsoft in this field is very
comprehensive, and appears to include some long-term planning and some
degree of protocol independence, it is not expected that there be any
redesign of, or significant additions to the dce/rpc pipes protocols, for
use in unix <-> unix administration.


strategic aim
-------------

to ensure that the administration of "domain" systems (NT 4.0, NT 5.0,
samba-ntdom and others) is flexible, powerful and secure.  this to be
achieved by ensuring that those responsible for the development of such
systems get a full, public peer review of the specification and to ensure
that the above aims are adhered to in the implementation. 

i don't mind the "let's tweak it a bit so it makes everyone else
incompatible when we actually release it" games, as long as everyone else,
once they've caught up, doesn't find any nasty surprises.  it only
reflects badly on the "leaders", long-term.  nicely counter-productive,
and not exactly what the users want, which is what counts in the end...


luke (samba team)


<a href="mailto:lkcl at switchboard.net"  > Luke Kenneth Casson Leighton  </a>
<a href="http://mailhost.cb1.com/~lkcl"> Samba Consultancy and Support </a>