Hi, to, 2003-12-11 kello 16:20, Grosswiler Roger kirjoitti: > hei, You seem to have guessed my nationality. ;) > > /lib/security/$ISA/pam_unix.so > > account required /lib/security/$ISA/pam_winbind.so > i haven't entered this! what is it for?? he's looking for an existing > account?? > > password Directly from the manual page of winbindd: "The pam_winbind module in the 2.2.2 release only supports the auth and account module-types. The latter simply performs a getpwnam() to verify that the system can obtain a uid for the user. If the libnss_winbind library has been correctly installed, this should always succeed." It is nice to note that while the package that provides winbindd is samba-common-3.0 the manual page talks about 2.2.2 release! ;) Actually I think this should be "sufficient" rather than "required" and the account-lines should be something like following: account sufficient /lib/security/$ISA/pam_winbind.so account required /lib/security/$ISA/pam_unix.so If I understood pam correctly this would say that if pam_winbind.so was able to provide getpwnam() for the requesting service then the stack ends there. If it failed the next one in the stack would be consulted and then it would be pam_unix.so which is required. I guess pam_winbind.so does probably a little bit more in 3.0 release than 2.2.2 release but that to confirm that guess some additional documentation would be required. Have you read the docs? I had not until now. ;) In case you have not either there are several files that have outdated and dated material: man winbindd - which is outdated /usr/share/doc/pam_smb-1.1.7 /usr/share/doc/pam-0.77 The pam_smb quite simply states that it requires the user information to be present in the password file. So it does not provide support for fetching and generating "getpwent()" information from the NT server. If you run swat you'll notice that there are options for running a script that creates user accounts when they try to login first time. If this works with pam_smb then you would not need winbindd. What winbindd does is to generate the password-file and group information from the "air" and from the DOMAIN server. It reserves an uid for the user from the uid-map and maps user's groups from DOMAIN groups to local gids from the gid-map. Therefore you don't need the user and group information to be present in the group and password files. Users home directory is not required to be present but if it is missing it will lead to trouble when running certain applications. GDM should no require the users home directory to be present as the default configuration saves .Xauthority information to /tmp if user's home directory is not present. The winbindd only works with applications that are pam aware and I guess that some critical applications in the gnome environment are not, which breaks the gnome desktop for winbindd users that are not present in the password file. I am not sure if this is the way it works but this is how I explained it to myself after reading the docs. Regards, -- Mauri Sahlberg <Mauri.Sahlberg@xxxxxxxxxxxxxxxx> Claymountain Solutions Oy
