Hi Tony,
> I'm running samba3x-3.5.10-0.110.el5_8.x86_64 on a fully updated
> CentOS-5.8 system as PDC.
>
> We upgraded our lab machines to Win7 over the summer
>
> The logins work ok and the homes share is being mounted from a
> separate fileserver. However the login batch command script is not
> running.
I have RHEL 5.4 with servnet Samba3.4 RPMS and it works OK with Windows
7 clients, besides a few Windows Vista and Windows XP ones. Even with
different releases and package sources our setups should work the same.
I know this for sure because one of my BDCs run RHEL 5.6 with RHEL own
Samba3.6 packages, which didn't exist on previous releases for RHEL 5.x
and this also didn't for CentOS 5.x where x < 6.
> Part of smb.conf
>
> logon script = %G.cmd
I guess this is your problem, because this hurt me with my first setup
(and it was before I had Windows 7 clients). From "man smb.conf":
%G primary group name of %U.
Are you sure your users have the correct primary group set? "Primary
group" is a Unix concept which doesn't exist in the Windows world. As
you didn't sent the rest of your smb.conf and your NSS/PAM config files
I don't know from there your PDC user information comes and how
Samba/Windows user and group definitions map to Unix user and groups.
My first setup had all users getting the same Unix group, which was
something generic such as "users", and was not mapped to any
Samba/Windows group. I have a few Unix groups which are not mapped
because they are used only for Unix (actually Linux) sysadmins and
applications.
I changed my user creation policies and procedures so the primary user
group was set to the unix group mapped to the "main" Samba/Windows
group
for the new user, and manually set the correct primary group for all old
users. It was quite a bit of work but I could not see any other way as
some (most) of my users were members of multiple Samba/Windows groups.
The "main" Samba/Windows group is what MS calls "organizational
group":
it reflects the user position as a member of a company department or
project.
Try using the command "id user_name" for a few users and check the if
the gid (which is the primary user group) is mapped to an existing
Samba/Windows group, and then chech if the Samba/Windows group has a
login script with the expected name at the correct path.
For example, my own regular user is:
# id lozano
uid=563(lozano) gid=508(suporte)
groups=508(suporte),548(ntaccount),100(users)
gid=508(suporte) is mapped to a Samba/Windows group of the same name.
While group 548(ntaccount) is mapped to the Samba/Windows "Account
Operators" group and grupo 100(users) is mapped to no Samba/Windows
group and is used by us to flag users with shell access to our servers.
I can check de Samba/Windows group memberships and mappings using the
net command from Samba, for example:
# net user info lozano
Enter root's password:
suporte
Account Operators
# net groupmap list
Enter root's password:
[... filtered ...]
Account Operators (S-1-5-32-548) -> ntaccount
suporte (S-1-5-21-2052653627-1561675057-495535119-1020) -> suporte
Also beware the factory settings for RHEL and CentOS systems is to
create a "private group" with its name equal to the user name for all
new users, so user "lozano" would have as its gid "lozano".
But "lozano"
was a Unix-only group and this didn't enabled us to use %G in any
effective way inside the Windows login script.
See for example a Unix-only user which is used by us to run a few cron
scripts:
# id analista
uid=500(analista) gid=100(users) groups=100(users),99(nobody),508(suporte)
# net user info analista
Enter root's password:
Failed to get groups for 'analista' with: Could not map names to SIDs
Hope this long message helps.
[]s, Fernando Lozano