This content has been marked as final. Show 2 replies
user13689398 wrote:When you login the login system will probably try to determine all the users groups, which means that it will search through, in this case, both the local files and the LDAP system, even if the user was found in the local /etc/passwd file.
I am having a problem with nsswitch.conf on solaris 9. I have the following lines in my nsswitch.conf:
passwd: files [SUCCESS=return NOTFOUND=continue UNAVAIL=continue TRYAGAIN=1] ldap
group: files [SUCCESS=return NOTFOUND=continue UNAVAIL=continue TRYAGAIN=1] ldap
The problem is with the "group" line. For some reason, when I log in with a valid unix id (passes passwd validation using "files"), the group evalutes to NOTFOUND. I know this to be the case because when I try to log in, the server is calling my ldap process to find the group, even when I log in with a local unix account. If I change the group line to:
group: files [SUCCESS=return NOTFOUND=return UNAVAIL=continue TRYAGAIN=1] ldap, my local login will work, (because of NOTFOUND=return) but then I can't log in with ldap user ids.
I think the above instructions (SUCCESS=return NOTFOUND=return UNAVAIL=continue TRYAGAIN=1) makes more sence when looking up a single group, and not so much sence when login in and getting all the users groups...
/etc/passwd for the user in question is:I'm sorry, but which group did it not find?
and /etc/group is:
Why is unix not finding the group?Well, since the users GID in /etc/passwd is '100', Solaris will understand that that is group 'netrac', so you don't have to put the user in the group netrac as well..
Thanks in advance for any help you can give!
I.e: the user will belong to its primary group (the group defined in /etc/passwd), so you don't have to add the user to the primary group in /etc/group ..
Thanks for the reply.
I have tried to test with other users from the "netrac" group as well who do not appear in /etc/passwd with identical results.
From the id command above, it looks to me that when the nsswitch.conf is run on these users or on embr_dev, the group line should trigger SUCCESS since the unix group is defined, but it does not. For some reason, it triggers NOTFOUND. I am trying to figure out why.