Luke Kenneth Casson Leighton
1998-Jan-03 20:27 UTC
NTDOM: SAMBA: NT 3.51 / 4.0 Domains for UNIX.
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@switchboard.net" > Luke Kenneth Casson Leighton </a> <a href="http://mailhost.cb1.com/~lkcl"> Samba Consultancy and Support </a>