I'm building a samba PDC and have had some problems with login scripts....
In Novell it's safe to use a single login script for everybody and let the
"map" commands fail on those volumes that the user does not have
access to.
"net use" (at least on my machine) prompts for a password if it
can't map a
drive due to permissions. This is not a good thing to happen in a login
script :-(
I tried to find a way to get "net use" to fail silently, and not
prompt for
a password if the initial attempt failed. Am I missing something? Perhaps
there's a win 98 or samba configuration parameter for disabling further
attempts when connecting?
I then tried both an older (3.6) and new version of KiXtart, but it seemed
unable to get group info from samba 2.2.3a, the ingroup function would
always return 0 regardless of a user's group memberships.
Next I found a few scripts designed to generate the login script
dynamically on the server side, ntlogon.py from freshmeat looked like the
most promising, but it was not set up to enumerate a users secondary group
memberships, it only pulls %U and %G from samba. None of the tools I found
were set up to parse /etc/gshadow directly, or even shell execute "groups
%U > sometempfile" for some later parsing of the "user : primgroup
secgroup
secroup2" output
Lastly I found
http://lists.samba.org/pipermail/samba-ntdom/1999-March/037333.html
>We have a workaround for this. In the netlogon directory I have created a
>directory for each group, like this:
>
>drwxr-x--- 2 root ccwstyr 1024 Apr 29 1998 ccwstyr/
>drwxr-x--- 2 root larare 1024 Apr 29 1998 larare/
>drwxr-x--- 2 root stolpsko 1024 Apr 29 1998 stolpskott/
>
>In each dir, I have a dummy file:
>
>-rw-r--r-- 1 root root 0 Apr 29 1998 dummy
>
>You can only see the dummy file in a directory if you're in that group.
By
>using some 'if exists' in the login script its possible to make
connections
>per group:
>
>if exist \\stalin\netlogon\ccwstyr\dummy net use s: \\stalin\styrelse /yes
This looks like the most promising so far, but I thought I might ask the
list if there was a "better way" before going ahead with this... (and
by
"better way" I don't mean maintaining per-user login scripts)
Adam