Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a strange problem on an debian lenny server. The server is a NIS client to share users/groups with another server and in the sudoers file the following is placed:

%groupX ALL=(ALL) ALL

So that members of groupX have sudo rights. Furthermore I have a user that is part of the group:

uid=1234(user.name) gid=1234(user.name) groups=1234(user.name),1001(groupX),<snip>

But still when the user tries to sudo he gets an error. The other group users can sudo perfectly fine.

This has happened once before, but then it was enough to remove, synchronise and re-add the user to the group. This didn't work this time.

In /var/log/auth.log the following default error is noted:

Jul  6 11:08:35 servername sudo: user.name : user NOT in sudoers ; TTY=pts/1 ; PWD=/home/u/user.name ; USER=root ; COMMAND=/bin/bash

Does anyone know how to fix this?

share|improve this question
    
So what was the error, and what is in your auth.log? –  womble Jul 9 '11 at 9:46
    
@womble I didn't think it was that relevant since it was just the default user not in sudoers error, but I've added it. –  dtech Jul 10 '11 at 16:54
add comment

1 Answer

up vote 2 down vote accepted

It probably would help if we know the output of auth.log. However, it sounds like authentication is going to the NIS first, like so under Red Hat:

passwd:     nisplus, files
shadow:     nisplus, files
group:      nisplus, files

Or in some distributions:

passwd:     nisplus, compat
shadow:     nisplus, compat
group:      nisplus, compat

If you need to have users sudo on that server, you will need to have local accounting definitions take precedence like so:

passwd:     files, nisplus
shadow:     files, nisplus
group:      files, nisplus

Keep in mind that this may prevent the users from accessing NIS resources, depending on how the auth stacks are configured. Verify that your pam configuration will not prevent you from auth against NIS after you auth locally.

EDIT: Okay, reviewing on how you can use NIS with sudo, do you know if that user exists on the local system? Assuming that nsswitch is looking at the local files, it is possible that is taking precedence first over the user in NIS.

share|improve this answer
    
I don't think this will solve the problem, since the problem is that 1 (nis) users from a (nis) group cannot sudo, while others from the same (nis) group can. –  dtech Jul 10 '11 at 16:47
    
You're right. However, after thinking it over, the problem is probably the other way around - he may have a local user that is being authenticated first over NIS and that user does not exists in the wheel group on the server. –  Rilindo Jul 10 '11 at 17:33
    
Well I checked that, and there is absolutely no local user with the same username. Also for example his password changes on the server when the pass is changed on the NIS server so it really is that user –  dtech Jul 10 '11 at 17:36
1  
Marking as solved because the final solution was to set the order in nsswitch.conf to group: files nis though I don't 100% understand the reasons behind it –  dtech Oct 13 '11 at 0:14
    
I suspect it's an issue with the pam configuration which the server, in that case. It might be best you review your existing pam configuration and see if that would be causing the initial problem. –  Rilindo Oct 13 '11 at 2:48
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.