Jerome, Thanks you for your feedback. I will be updating the HOWTO over the next few days as I need to create a new PDF for the HOWTO book by Monday. Your feedback is in good time. Thanks.
- John T. On Thu, 8 Jan 2004, [ISO-8859-15] J�r�me Fenal wrote: > Hi list, hi John, > > having seen last week a post (see > http://marc.theaimsgroup.com/?m=107341768923846) that remind me some > quirks I encountered, I'd like to see a preamble added to the chapter 12 > of the howto. It concerns the diffent types of admin you will need in a > PDC setup. > I say preamble, but it could be found anywhere else, as long as it could > be found (I have lost long hours struggling with this) ;-) > > It applies to NT4 domain control, but may apply as well to ADS, when > Samba will be ready (YMMV, I never used Samba in ADS mode). > > It could be as follow : > > � > Administrative tasks that will need to be done with or beside Samba will > be of two types : > - the one concerning directly the domain, and thus Samba as a PDC, > - and the one concerning the clients, eg. as local workstation/server > administrator. > > These are really different as the first will in fact concern the Unix > security model that Samba follows closely, the latest are facilities > from the Windows paradigms, such as the "Domain Admins" domain group. > > The first will always need root priviledges, the second are discussed > below regarding to how to map a Unix group to the NT4 "Domain Admins" one. > > Root priviledges are basically needed to add, remove, and modify (group > membership for instance) Unix accounts, and are given to a user having a > uid equal to zero. It could also be given to users specified in the > "admin users =" clause of smb.conf. The downside of this is that the > samba user is mapped to root (which is what we asked for), not only for > account management, but for _all_ tasks, eg. also for accessing shares, > creating files and so on. > These users thus should not be used for day to day work, but only for > domain administration purposes. > But it could be mixed with the "Domain Admins" group (mapped to Unix > group domadmin or ntadmin), just by specifying "admin users = root > @ntadmin @domadmin" in smb.conf. > This will allow paradigms similar to the one found in NT4 domain > administration, but with the downside cited below. > > What should should be done is to have two separate groups, say domadmin > for domain administration, ntadmin for NT client administration (such as > a loging with local administrative rights on a workstation). > > domadmin should have accounts used only for domain administration > (add/remove workstations, servers, users), eg. tasks that could be > accomplished through the use of USRMGR.EXE and SRVMGR.EXE. > > ntadmin should be mapped to "Domain Admins" group (rid=512). > > ntadmin should not be found in the "admin users =" clause, which should > only read : > admin users = root @domadmin > > Accounts in ntadmin group should not be seen in domadmin group, and reverse. > > Accounts in domadmin are nominative, just as should be all accounts in > secure minded organisations. To differentiate them from normal accounts, > and could be named as "admin-da-" ("d" could be seen as domain or > directory administrator) followed by the name of the standard account of > the user (eg. would be admin-da-jfenal for me). > > In the same manner, accounts in ntadmin could be as "admin-sa-" ("s" for > station or server administrator). > > So an administrative user would have two to three accounts : > - name, > - admin-wa-name, > - and possibly admin-da-name. > � > > This is more or less what I'm currently writing (in french) in a > document for one of my clients. > > The account naming norm is what I am currently implementing and could be > avoided in the howto, but it really shows what are the differences > between the tasks, and also allows a technician to have administration > rights on workstations, and not on the domain. > > Commments are welcome, corrections too. > > Regards, > > J�r�me > > -- John H Terpstra Email: [EMAIL PROTECTED] -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
