[ale] Samba setup

Thu Aug 4 14:58:37 EDT 2005

On Aug 4, 2005, at 9:21 AM, Michael Trausch wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Mark Wright wrote:
>
>> I added a root passwd to the smbpasswd file and then made sure I  
>> added
>> myself.  I did put a UID for myself on the system.  After I did  
>> this I
>> have changed the failure message (which I forgot to mention in the
>> original post)  Now I am getting a message that says a "machine  
>> account
>> does not exist."
>>
>> That helps.  There is a script that is supposed to create this.   
>> Here is
>> the log data from this failure.
>>
>> [2005/08/03 20:30:08, 0] rpc_server/srv_samr_nt.c:_samr_create_user 
>> (2324)
>>   _samr_create_user: Running the command `/usr/sbin/useradd -s
>> /bin/false \-d /dev/null l200772$' gave 1
>> useradd: unable to lock password file
>>
>> "unable to lock password file?"  What is that for?  More reading.....
>>
>>
>
> Okay.
>
> You need to create the Machine Trust Account on the domain controller.
> Also, ever user that you want to authenticate, must have a UNIX logon
> and a Samba logon.  You do not need to explictly create their home  
> share
> - -- only their extra fileshares that they would use for the  
> purpose of
> filesharing, and make sure that it has a reasonable umask so that they
> can actually "share".
>
> The Machine Trust Account (both in UNIX and Samba) has a $ in it.  So,
> for a computer named "fd0man"
>
> To create the Machine Account:
>
> "To add machine account, use your system script, most likely  
> adduser. If
> your system does not support user names with $ (i.e. FreeBSD), you  
> must
> edit your password database to add it manualy. So on FreeBSD, use  
> vipw."

Using Ubuntu...
here is the machine account script that SAMBA had as default in smb.conf

add machine script = /usr/sbin/useradd -s /bin/false \-d /dev/null %u

>
> And in Samba:  smbpasswd -a -m <machine-name>$
>
> "The system accounts for machines do not need login shell neither home
> dir, so use false as login shell and /dev/null as home dir.
> After adding system accounts, you must use smbpasswd to add Samba
> machine account. There you can use $ in usernames."
>
> Now, some of the other quirks that I've found -- I use a mostly  
> default
> setup (it's secure and it works).
>
> ** If you need extra drives, then give them those drives via a logon
> script (or scripts) in the \\SERVER\netlogon share.
>
> ** The user that is the Domain Administrator, at least in Samba  
> 2.x, not
> sure if this is still true in 3.x, because I haven't tried to go  
> against
> it with my network, must be 'root'.  This means that Windows NT
> "Administrator" user name can't be a domain administrator.  But  
> that's okay.
>
> You can map Windows system groups to UNIX groups.  If you want a  
> user to
> be a Windows Administrator on the local machines when they login to
> them, you can set that.  Same for Power User and all of that -- it's
> handled directly on Samba.  If you do not do this, I believe they all
> default to Administrators.
>
> You have the [homes] section defined, as well as the multiple user
> definitions.  This is redundant -- they will get two shares  
> available to
> them, however, Windows NT/2k/XP will connect to the [homes] share --
> that's the one offered as the user's "network home", which will  
> hold the
> Windows profile (and be mapped as Drive Z:).
>
> In reference to the above, I'd recommend that you remove your  
> dedicated
> [Profiles] section and store that in each user's UNIX home directory.
> This keeps things centralized, and that's their system accountable
> space, anyway.  This makes it easier because then the share for the
> "roaming profiles" is always available right with the user's
> automatically mapped Z: drive.  (\\server\homes\profile or something

Not sure what you are recommending.  The user definitions at the end  
of the testparm output were created by the SAMBA scripts.  Is this  
redundant with the [homes] section "on"?
> like that.)
>
> I would recommend that you create a seperate drive/share so that they
> can share their files amongst each other and keep their home  
> directories
> private.  Please note that their home directories will also contain
> their registry settings and so forth from Windows.  You don't want
> everying having access to that.  That's just silly.  Put that  
> command in
> your logon.bat in your Netlogon share.

I will do this when I get the domain authentication working.  I am  
going to recommend a backup strategy that uses external drives as the  
shared data folders.
I am thinking that one firewire drive could be the shared folder and  
I could use rsync to copy it to a second drive that could be removed  
to a secure location.  With three spare
drives this could provide off site disk backup of their data each week.

>
> Lastly, I would recommend that you upgrade this setup to Samba 3 -- it
> has more up-to-date support for systems on the network, and as your
> userbase there migrates upward towards Windows XP, you won't have any
> issues with the Samba server running 3.0.  It does a great job.
It is SAMBA 3

>
>     - Mike
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFC8hZ1PXInbkqM7nwRAj6EAJ9dDtnrLPlsn3e0QhE6rt0LP/ZMjwCfXNQe
> PGF9f5WSRyN+a+rDSNDMY2s=
> =N+02
> -----END PGP SIGNATURE-----
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://www.ale.org/mailman/listinfo/ale
>

Mark Wright
NASA Maintenance Specialist
Mark_Wright at NASAsupport.com
www.nasasupport.com

1.800.724.9692

"Whatever It Takes"

-------------- next part --------------
An HTML attachment was scrubbed...