Discussion:
Sudo works for full access, but not on a per command or host level.
(too old to reply)
Macklin, Jason
2012-10-15 20:34:05 UTC
Permalink
Hi,

I apologize up front if this is obvious, but I'm having issues configuring sudo privileges.

I currently have an IPA server running FreeIPA 2.2 with sudo configured for our administrators on all hosts. This works fantastic! As soon as I attempt to configure a more specific sudo rule it does not work. In my troubleshooting, I have noticed that from the same host my admin level privileges work, but with another user account setup to just run one command, it fails. I have turned on sudo debugging and the only thing I can find that looks out of sorts is the following:

sudo: host_matches=0

As soon as I move the user account that is failing into the admin group it starts to work.

I have attempted every iteration of sudo configuration on the server that I can think of. I have setup HBAC and given that a shot as well. At this point I'm completely stumped and would appreciate any help that I can get!

Thank you in advance for your assistance,
Jason
Dmitri Pal
2012-10-15 20:46:20 UTC
Permalink
On 10/15/2012 04:34 PM, Macklin, Jason wrote:
>
> Hi,
>
>
>
> I apologize up front if this is obvious, but I'm having issues
> configuring sudo privileges.
>
>
>
> I currently have an IPA server running FreeIPA 2.2 with sudo
> configured for our administrators on all hosts. This works
> fantastic! As soon as I attempt to configure a more specific sudo
> rule it does not work. In my troubleshooting, I have noticed that
> from the same host my admin level privileges work, but with another
> user account setup to just run one command, it fails. I have turned
> on sudo debugging and the only thing I can find that looks out of
> sorts is the following:
>
>
>
> sudo: host_matches=0
>
>
>
> As soon as I move the user account that is failing into the admin
> group it starts to work.
>
>
>
> I have attempted every iteration of sudo configuration on the server
> that I can think of. I have setup HBAC and given that a shot as
> well. At this point I'm completely stumped and would appreciate any
> help that I can get!
>

What does sudo test return?
Does it return the expected results?

Can you be more specific about the rule you have?
Based on the description you have a rule that points to a specific user.
If this user is referred to in the rule explicitly sudo does not work
properly but if you move user to a group that is referenced by the rule
then the rule works as expected. Is this correct description of the problem?

I assume that you are turning off allow_all rule that allows anyone to
do anything by default, right?


>
>
> Thank you in advance for your assistance,
>
> Jason
>
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-***@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users


--
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
Dmitri Pal
2012-10-15 21:58:11 UTC
Permalink
On 10/15/2012 04:46 PM, Dmitri Pal wrote:
> On 10/15/2012 04:34 PM, Macklin, Jason wrote:
>>
>> Hi,
>>
>>
>>
>> I apologize up front if this is obvious, but I'm having issues
>> configuring sudo privileges.
>>
>>
>>
>> I currently have an IPA server running FreeIPA 2.2 with sudo
>> configured for our administrators on all hosts. This works
>> fantastic! As soon as I attempt to configure a more specific sudo
>> rule it does not work. In my troubleshooting, I have noticed that
>> from the same host my admin level privileges work, but with another
>> user account setup to just run one command, it fails. I have turned
>> on sudo debugging and the only thing I can find that looks out of
>> sorts is the following:
>>
>>
>>
>> sudo: host_matches=0
>>
>>
>>
>> As soon as I move the user account that is failing into the admin
>> group it starts to work.
>>
>>
>>
>> I have attempted every iteration of sudo configuration on the server
>> that I can think of. I have setup HBAC and given that a shot as
>> well. At this point I'm completely stumped and would appreciate any
>> help that I can get!
>>
>
> What does sudo test return?

Yes I meant HBAC. I might confused you and myself so let us start over.

First we need to make sure that the authentication happens correctly so
if HBAC is set to allow you should see in the SSSD log that access is
granted. That will limit the problem to just SUDO. If you have the
allow_all HBAC rule and no other rules then we can probably skip this
step and move on to trying to solve the actual SUDO part.

So with SUDO one of the known issues is the long vs short hostname. Do
you by any chance use a short host name for that host?
If names are FQDN the next step would be to use ldapsearch from the
client and see what LDAP entries the server would return.

>>
>>
>> Thank you in advance for your assistance,
>>
>> Jason
>>
>>
>>
>> _______________________________________________
>> Freeipa-users mailing list
>> Freeipa-***@redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>
>
> --
> Thank you,
> Dmitri Pal
>
> Sr. Engineering Manager for IdM portfolio
> Red Hat Inc.
>
>
> -------------------------------
> Looking to carve out IT costs?
> www.redhat.com/carveoutcosts/
>
>
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-***@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users


--
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
Macklin, Jason
2012-10-16 14:05:38 UTC
Permalink
When I become the user in question I see the following in the sssd log.

[ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule [test]

I think this is a sudo problem before anything else. For a user in which sudo works, host_matches = 1 always returns when debugging is on. For a user that does not work host_matches always equals 0 (zero).

I am open to troubleshooting the ldap configuration as I am not convinced that it is referencing the host properly. I enroll the clients using FQDN, but noticed that initially, domainname and nisdomainname qould return (none). Fixing these to show the correct domain did not change the behavior of the nodes though.

Thanks again!

Jason

From: freeipa-users-***@redhat.com [mailto:freeipa-users-***@redhat.com] On Behalf Of Dmitri Pal
Sent: Monday, October 15, 2012 5:58 PM
To: freeipa-***@redhat.com
Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.

On 10/15/2012 04:46 PM, Dmitri Pal wrote:
On 10/15/2012 04:34 PM, Macklin, Jason wrote:
Hi,

I apologize up front if this is obvious, but I'm having issues configuring sudo privileges.

I currently have an IPA server running FreeIPA 2.2 with sudo configured for our administrators on all hosts. This works fantastic! As soon as I attempt to configure a more specific sudo rule it does not work. In my troubleshooting, I have noticed that from the same host my admin level privileges work, but with another user account setup to just run one command, it fails. I have turned on sudo debugging and the only thing I can find that looks out of sorts is the following:

sudo: host_matches=0

As soon as I move the user account that is failing into the admin group it starts to work.

I have attempted every iteration of sudo configuration on the server that I can think of. I have setup HBAC and given that a shot as well. At this point I'm completely stumped and would appreciate any help that I can get!

What does sudo test return?

Yes I meant HBAC. I might confused you and myself so let us start over.

First we need to make sure that the authentication happens correctly so if HBAC is set to allow you should see in the SSSD log that access is granted. That will limit the problem to just SUDO. If you have the allow_all HBAC rule and no other rules then we can probably skip this step and move on to trying to solve the actual SUDO part.

So with SUDO one of the known issues is the long vs short hostname. Do you by any chance use a short host name for that host?
If names are FQDN the next step would be to use ldapsearch from the client and see what LDAP entries the server would return.



Thank you in advance for your assistance,
Jason




_______________________________________________

Freeipa-users mailing list

Freeipa-***@redhat.com<mailto:Freeipa-***@redhat.com>

https://www.redhat.com/mailman/listinfo/freeipa-users




--

Thank you,

Dmitri Pal



Sr. Engineering Manager for IdM portfolio

Red Hat Inc.





-------------------------------

Looking to carve out IT costs?

www.redhat.com/carveoutcosts/<http://www.redhat.com/carveoutcosts/>








_______________________________________________

Freeipa-users mailing list

Freeipa-***@redhat.com<mailto:Freeipa-***@redhat.com>

https://www.redhat.com/mailman/listinfo/freeipa-users




--

Thank you,

Dmitri Pal



Sr. Engineering Manager for IdM portfolio

Red Hat Inc.





-------------------------------

Looking to carve out IT costs?

www.redhat.com/carveoutcosts/<http://www.redhat.com/carveoutcosts/>
Dmitri Pal
2012-10-16 14:32:32 UTC
Permalink
On 10/16/2012 10:05 AM, Macklin, Jason wrote:
>
> When I become the user in question I see the following in the sssd log.
>
>
>
> [ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC
> rule [test]
>
>
>
> I think this is a sudo problem before anything else. For a user in
> which sudo works, host_matches = 1 always returns when debugging is
> on. For a user that does not work host_matches always equals 0 (zero).
>
>
>

Is there any way to see a more detailed debug log from sudo then? It
should show what it is looking for and what it is getting back from the
server.

> I am open to troubleshooting the ldap configuration as I am not
> convinced that it is referencing the host properly. I enroll the
> clients using FQDN, but noticed that initially, domainname and
> nisdomainname qould return (none). Fixing these to show the correct
> domain did not change the behavior of the nodes though.
>
>
>
> Thanks again!
>
>
>
> Jason
>
>
>
> *From:*freeipa-users-***@redhat.com
> [mailto:freeipa-users-***@redhat.com] *On Behalf Of *Dmitri Pal
> *Sent:* Monday, October 15, 2012 5:58 PM
> *To:* freeipa-***@redhat.com
> *Subject:* Re: [Freeipa-users] Sudo works for full access, but not on
> a per command or host level.
>
>
>
> On 10/15/2012 04:46 PM, Dmitri Pal wrote:
>
> On 10/15/2012 04:34 PM, Macklin, Jason wrote:
>
> Hi,
>
>
>
> I apologize up front if this is obvious, but I'm having issues
> configuring sudo privileges.
>
>
>
> I currently have an IPA server running FreeIPA 2.2 with sudo
> configured for our administrators on all hosts. This works
> fantastic! As soon as I attempt to configure a more specific sudo
> rule it does not work. In my troubleshooting, I have noticed that
> from the same host my admin level privileges work, but with another
> user account setup to just run one command, it fails. I have turned
> on sudo debugging and the only thing I can find that looks out of
> sorts is the following:
>
>
>
> sudo: host_matches=0
>
>
>
> As soon as I move the user account that is failing into the admin
> group it starts to work.
>
>
>
> I have attempted every iteration of sudo configuration on the server
> that I can think of. I have setup HBAC and given that a shot as
> well. At this point I'm completely stumped and would appreciate any
> help that I can get!
>
>
> What does sudo test return?
>
>
> Yes I meant HBAC. I might confused you and myself so let us start over.
>
> First we need to make sure that the authentication happens correctly
> so if HBAC is set to allow you should see in the SSSD log that access
> is granted. That will limit the problem to just SUDO. If you have the
> allow_all HBAC rule and no other rules then we can probably skip this
> step and move on to trying to solve the actual SUDO part.
>
> So with SUDO one of the known issues is the long vs short hostname. Do
> you by any chance use a short host name for that host?
> If names are FQDN the next step would be to use ldapsearch from the
> client and see what LDAP entries the server would return.
>
>
>
>
> Thank you in advance for your assistance,
>
> Jason
>
>
>
>
> _______________________________________________
>
> Freeipa-users mailing list
>
> Freeipa-***@redhat.com <mailto:Freeipa-***@redhat.com>
>
> https://www.redhat.com/mailman/listinfo/freeipa-users
>
>
>
>
> --
> Thank you,
> Dmitri Pal
>
> Sr. Engineering Manager for IdM portfolio
> Red Hat Inc.
>
>
> -------------------------------
> Looking to carve out IT costs?
> www.redhat.com/carveoutcosts/ <http://www.redhat.com/carveoutcosts/>
>
>
>
>
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-***@redhat.com <mailto:Freeipa-***@redhat.com>
> https://www.redhat.com/mailman/listinfo/freeipa-users
>
>
>
>
> --
> Thank you,
> Dmitri Pal
>
> Sr. Engineering Manager for IdM portfolio
> Red Hat Inc.
>
>
> -------------------------------
> Looking to carve out IT costs?
> www.redhat.com/carveoutcosts/ <http://www.redhat.com/carveoutcosts/>
>
>
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-***@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users


--
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
Macklin, Jason
2012-10-16 15:09:10 UTC
Permalink
Dmitri,

I will give you everything I've got. If I can provide something else, let me know!

Working User:

Sudo debug output:

[***@dbduwdu062 log]$ sudo -l
sudo: ldap_set_option: debug -> 0
sudo: ldap_set_option: tls_checkpeer -> 1
sudo: ldap_set_option: tls_cacertfile -> /etc/ipa/ca.crt
sudo: ldap_set_option: tls_cacert -> /etc/ipa/ca.crt
sudo: ldap_set_option: ldap_version -> 3
sudo: ldap_set_option: timelimit -> 15
sudo: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT, 5)
sudo: ldap_start_tls_s() ok
sudo: ldap_sasl_bind_s() ok
sudo: no default options found in ou=SUDOers,dc=dbr,dc=roche,dc=com
sudo: user_matches=1
sudo: host_matches=1
sudo: sudo_ldap_lookup(52)=0x82
[sudo] password for jmacklin:
Matching Defaults entries for jmacklin on this host:
requiretty, !visiblepw, always_set_home, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS", env_keep+="MAIL PS1
PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY
LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin

sudo: ldap search '(|(sudoUser=jmacklin)(sudoUser=%jmacklin)(sudoUser=%dbr)(sudoUser=%admins)(sudoUser=ALL))'
sudo: ldap search 'sudoUser=+*'
User jmacklin may run the following commands on this host:
(root) ALL

/var/log/secure output:

Oct 16 11:00:03 dbduwdu062 sudo: pam_unix(sudo:auth): authentication failure; logname=jmacklin uid=0 euid=0 tty=/dev/pts/1 ruser=jmacklin rhost= user=jmacklin
Oct 16 11:00:04 dbduwdu062 sudo: pam_sss(sudo:auth): authentication success; logname=jmacklin uid=0 euid=0 tty=/dev/pts/1 ruser=jmacklin rhost= user=jmacklin
Oct 16 11:00:04 dbduwdu062 sudo: jmacklin : TTY=pts/1 ; PWD=/var/log ; USER=root ; COMMAND=list

Non-working user:

Sudo debug output:

[***@dbduwdu062 ~]$ sudo -l
sudo: ldap_set_option: debug -> 0
sudo: ldap_set_option: tls_checkpeer -> 1
sudo: ldap_set_option: tls_cacertfile -> /etc/ipa/ca.crt
sudo: ldap_set_option: tls_cacert -> /etc/ipa/ca.crt
sudo: ldap_set_option: ldap_version -> 3
sudo: ldap_set_option: timelimit -> 15
sudo: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT, 5)
sudo: ldap_start_tls_s() ok
sudo: ldap_sasl_bind_s() ok
sudo: no default options found in ou=SUDOers,dc=dbr,dc=domain,dc=com
sudo: user_matches=1
sudo: host_matches=0
sudo: sudo_ldap_lookup(52)=0x84
[sudo] password for asteinfeld:
Sorry, user asteinfeld may not run sudo on dbduwdu062

/var/log/secure output:

Oct 16 11:05:34 dbduwdu062 sudo: pam_unix(sudo:auth): authentication failure; logname=asteinfeld uid=0 euid=0 tty=/dev/pts/3 ruser=asteinfeld rhost= user=asteinfeld
Oct 16 11:05:35 dbduwdu062 sudo: pam_sss(sudo:auth): authentication success; logname=asteinfeld uid=0 euid=0 tty=/dev/pts/3 ruser=asteinfeld rhost= user=asteinfeld
Oct 16 11:05:35 dbduwdu062 sudo: asteinfeld : command not allowed ; TTY=pts/3 ; PWD=/home2/asteinfeld ; USER=root ; COMMAND=list

Cheers.
Jason



From: freeipa-users-***@redhat.com [mailto:freeipa-users-***@redhat.com] On Behalf Of Dmitri Pal
Sent: Tuesday, October 16, 2012 10:33 AM
To: freeipa-***@redhat.com
Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.

On 10/16/2012 10:05 AM, Macklin, Jason wrote:
When I become the user in question I see the following in the sssd log.

[ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule [test]

I think this is a sudo problem before anything else. For a user in which sudo works, host_matches = 1 always returns when debugging is on. For a user that does not work host_matches always equals 0 (zero).


Is there any way to see a more detailed debug log from sudo then? It should show what it is looking for and what it is getting back from the server.


I am open to troubleshooting the ldap configuration as I am not convinced that it is referencing the host properly. I enroll the clients using FQDN, but noticed that initially, domainname and nisdomainname qould return (none). Fixing these to show the correct domain did not change the behavior of the nodes though.

Thanks again!

Jason

From: freeipa-users-***@redhat.com<mailto:freeipa-users-***@redhat.com> [mailto:freeipa-users-***@redhat.com] On Behalf Of Dmitri Pal
Sent: Monday, October 15, 2012 5:58 PM
To: freeipa-***@redhat.com<mailto:freeipa-***@redhat.com>
Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.

On 10/15/2012 04:46 PM, Dmitri Pal wrote:
On 10/15/2012 04:34 PM, Macklin, Jason wrote:
Hi,

I apologize up front if this is obvious, but I'm having issues configuring sudo privileges.

I currently have an IPA server running FreeIPA 2.2 with sudo configured for our administrators on all hosts. This works fantastic! As soon as I attempt to configure a more specific sudo rule it does not work. In my troubleshooting, I have noticed that from the same host my admin level privileges work, but with another user account setup to just run one command, it fails. I have turned on sudo debugging and the only thing I can find that looks out of sorts is the following:

sudo: host_matches=0

As soon as I move the user account that is failing into the admin group it starts to work.

I have attempted every iteration of sudo configuration on the server that I can think of. I have setup HBAC and given that a shot as well. At this point I'm completely stumped and would appreciate any help that I can get!

What does sudo test return?

Yes I meant HBAC. I might confused you and myself so let us start over.

First we need to make sure that the authentication happens correctly so if HBAC is set to allow you should see in the SSSD log that access is granted. That will limit the problem to just SUDO. If you have the allow_all HBAC rule and no other rules then we can probably skip this step and move on to trying to solve the actual SUDO part.

So with SUDO one of the known issues is the long vs short hostname. Do you by any chance use a short host name for that host?
If names are FQDN the next step would be to use ldapsearch from the client and see what LDAP entries the server would return.




Thank you in advance for your assistance,
Jason





_______________________________________________

Freeipa-users mailing list

Freeipa-***@redhat.com<mailto:Freeipa-***@redhat.com>

https://www.redhat.com/mailman/listinfo/freeipa-users





--

Thank you,

Dmitri Pal



Sr. Engineering Manager for IdM portfolio

Red Hat Inc.





-------------------------------

Looking to carve out IT costs?

www.redhat.com/carveoutcosts/<http://www.redhat.com/carveoutcosts/>









_______________________________________________

Freeipa-users mailing list

Freeipa-***@redhat.com<mailto:Freeipa-***@redhat.com>

https://www.redhat.com/mailman/listinfo/freeipa-users





--

Thank you,

Dmitri Pal



Sr. Engineering Manager for IdM portfolio

Red Hat Inc.





-------------------------------

Looking to carve out IT costs?

www.redhat.com/carveoutcosts/<http://www.redhat.com/carveoutcosts/>








_______________________________________________

Freeipa-users mailing list

Freeipa-***@redhat.com<mailto:Freeipa-***@redhat.com>

https://www.redhat.com/mailman/listinfo/freeipa-users




--

Thank you,

Dmitri Pal



Sr. Engineering Manager for IdM portfolio

Red Hat Inc.





-------------------------------

Looking to carve out IT costs?

www.redhat.com/carveoutcosts/<http://www.redhat.com/carveoutcosts/>
Dmitri Pal
2012-10-16 15:22:02 UTC
Permalink
On 10/16/2012 11:09 AM, Macklin, Jason wrote:
>
> Dmitri,
>
>
>
> I will give you everything I've got. If I can provide something else,
> let me know!
>
>
>
> *Working User:*
>
>
>
> *Sudo debug output:*
>
>
>
> [***@dbduwdu062 log]$ sudo -l
>
> sudo: ldap_set_option: debug -> 0
>
> sudo: ldap_set_option: tls_checkpeer -> 1
>
> sudo: ldap_set_option: tls_cacertfile -> /etc/ipa/ca.crt
>
> sudo: ldap_set_option: tls_cacert -> /etc/ipa/ca.crt
>
> sudo: ldap_set_option: ldap_version -> 3
>
> sudo: ldap_set_option: timelimit -> 15
>
> sudo: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT, 5)
>
> sudo: ldap_start_tls_s() ok
>
> sudo: ldap_sasl_bind_s() ok
>
> sudo: no default options found in ou=SUDOers,dc=dbr,dc=roche,dc=com
>
> sudo: user_matches=1
>
> sudo: host_matches=1
>
> sudo: sudo_ldap_lookup(52)=0x82
>
> [sudo] password for jmacklin:
>
> Matching Defaults entries for jmacklin on this host:
>
> requiretty, !visiblepw, always_set_home, env_reset,
> env_keep="COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS",
> env_keep+="MAIL PS1
>
> PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
> env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
> env_keep+="LC_MONETARY
>
> LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME
> LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
>
> secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin
>
>
>
> sudo: ldap search
> '(|(sudoUser=jmacklin)(sudoUser=%jmacklin)(sudoUser=%dbr)(sudoUser=%admins)(sudoUser=ALL))'
>
> sudo: ldap search 'sudoUser=+*'
>
> User jmacklin may run the following commands on this host:
>
> (root) ALL
>
>
>
> */var/log/secure output:*
>
>
>
> Oct 16 11:00:03 dbduwdu062 sudo: pam_unix(sudo:auth): authentication
> failure; logname=jmacklin uid=0 euid=0 tty=/dev/pts/1 ruser=jmacklin
> rhost= user=jmacklin
>
> Oct 16 11:00:04 dbduwdu062 sudo: pam_sss(sudo:auth): authentication
> success; logname=jmacklin uid=0 euid=0 tty=/dev/pts/1 ruser=jmacklin
> rhost= user=jmacklin
>
> Oct 16 11:00:04 dbduwdu062 sudo: jmacklin : TTY=pts/1 ; PWD=/var/log ;
> USER=root ; COMMAND=list
>
>
>
> *Non-working user:*
>
> * *
>
> *Sudo debug output:*
>
> * *
>
> [***@dbduwdu062 ~]$ sudo -l
>
> sudo: ldap_set_option: debug -> 0
>
> sudo: ldap_set_option: tls_checkpeer -> 1
>
> sudo: ldap_set_option: tls_cacertfile -> /etc/ipa/ca.crt
>
> sudo: ldap_set_option: tls_cacert -> /etc/ipa/ca.crt
>
> sudo: ldap_set_option: ldap_version -> 3
>
> sudo: ldap_set_option: timelimit -> 15
>
> sudo: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT, 5)
>
> sudo: ldap_start_tls_s() ok
>
> sudo: ldap_sasl_bind_s() ok
>
> sudo: no default options found in ou=SUDOers,dc=dbr,dc=domain,dc=com
>
> sudo: user_matches=1
>
> sudo: host_matches=0
>
> sudo: sudo_ldap_lookup(52)=0x84
>
> [sudo] password for asteinfeld:
>
> Sorry, user asteinfeld may not run sudo on dbduwdu062
>
>
>
> */var/log/secure output:*
>
> * *
>
> Oct 16 11:05:34 dbduwdu062 sudo: pam_unix(sudo:auth): authentication
> failure; logname=asteinfeld uid=0 euid=0 tty=/dev/pts/3
> ruser=asteinfeld rhost= user=asteinfeld
>
> Oct 16 11:05:35 dbduwdu062 sudo: pam_sss(sudo:auth): authentication
> success; logname=asteinfeld uid=0 euid=0 tty=/dev/pts/3
> ruser=asteinfeld rhost= user=asteinfeld
>
> Oct 16 11:05:35 dbduwdu062 sudo: asteinfeld : command not allowed ;
> TTY=pts/3 ; PWD=/home2/asteinfeld ; USER=root ; COMMAND=list
>
>
>
> Cheers.
>
> Jason
>


Please set sudoers_debug 2

http://www.doxer.org/learn-linux/modify-sudoers_debug-in-ldap-conf-to-debug-sudo-on-linux-and-solaris/
>
>
>
>
>
>
>
> *From:*freeipa-users-***@redhat.com
> [mailto:freeipa-users-***@redhat.com] *On Behalf Of *Dmitri Pal
> *Sent:* Tuesday, October 16, 2012 10:33 AM
> *To:* freeipa-***@redhat.com
> *Subject:* Re: [Freeipa-users] Sudo works for full access, but not on
> a per command or host level.
>
>
>
> On 10/16/2012 10:05 AM, Macklin, Jason wrote:
>
> When I become the user in question I see the following in the sssd log.
>
>
>
> [ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC
> rule [test]
>
>
>
> I think this is a sudo problem before anything else. For a user in
> which sudo works, host_matches = 1 always returns when debugging is
> on. For a user that does not work host_matches always equals 0 (zero).
>
>
>
>
> Is there any way to see a more detailed debug log from sudo then? It
> should show what it is looking for and what it is getting back from
> the server.
>
>
> I am open to troubleshooting the ldap configuration as I am not
> convinced that it is referencing the host properly. I enroll the
> clients using FQDN, but noticed that initially, domainname and
> nisdomainname qould return (none). Fixing these to show the correct
> domain did not change the behavior of the nodes though.
>
>
>
> Thanks again!
>
>
>
> Jason
>
>
>
> *From:*freeipa-users-***@redhat.com
> <mailto:freeipa-users-***@redhat.com>
> [mailto:freeipa-users-***@redhat.com] *On Behalf Of *Dmitri Pal
> *Sent:* Monday, October 15, 2012 5:58 PM
> *To:* freeipa-***@redhat.com <mailto:freeipa-***@redhat.com>
> *Subject:* Re: [Freeipa-users] Sudo works for full access, but not on
> a per command or host level.
>
>
>
> On 10/15/2012 04:46 PM, Dmitri Pal wrote:
>
> On 10/15/2012 04:34 PM, Macklin, Jason wrote:
>
> Hi,
>
>
>
> I apologize up front if this is obvious, but I'm having issues
> configuring sudo privileges.
>
>
>
> I currently have an IPA server running FreeIPA 2.2 with sudo
> configured for our administrators on all hosts. This works
> fantastic! As soon as I attempt to configure a more specific sudo
> rule it does not work. In my troubleshooting, I have noticed that
> from the same host my admin level privileges work, but with another
> user account setup to just run one command, it fails. I have turned
> on sudo debugging and the only thing I can find that looks out of
> sorts is the following:
>
>
>
> sudo: host_matches=0
>
>
>
> As soon as I move the user account that is failing into the admin
> group it starts to work.
>
>
>
> I have attempted every iteration of sudo configuration on the server
> that I can think of. I have setup HBAC and given that a shot as
> well. At this point I'm completely stumped and would appreciate any
> help that I can get!
>
>
> What does sudo test return?
>
>
> Yes I meant HBAC. I might confused you and myself so let us start over.
>
> First we need to make sure that the authentication happens correctly
> so if HBAC is set to allow you should see in the SSSD log that access
> is granted. That will limit the problem to just SUDO. If you have the
> allow_all HBAC rule and no other rules then we can probably skip this
> step and move on to trying to solve the actual SUDO part.
>
> So with SUDO one of the known issues is the long vs short hostname. Do
> you by any chance use a short host name for that host?
> If names are FQDN the next step would be to use ldapsearch from the
> client and see what LDAP entries the server would return.
>
>
>
>
>
> Thank you in advance for your assistance,
>
> Jason
>
>
>
>
>
> _______________________________________________
>
> Freeipa-users mailing list
>
> Freeipa-***@redhat.com <mailto:Freeipa-***@redhat.com>
>
> https://www.redhat.com/mailman/listinfo/freeipa-users
>
>
>
>
>
> --
> Thank you,
> Dmitri Pal
>
> Sr. Engineering Manager for IdM portfolio
> Red Hat Inc.
>
>
> -------------------------------
> Looking to carve out IT costs?
> www.redhat.com/carveoutcosts/ <http://www.redhat.com/carveoutcosts/>
>
>
>
>
>
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-***@redhat.com <mailto:Freeipa-***@redhat.com>
> https://www.redhat.com/mailman/listinfo/freeipa-users
>
>
>
>
>
> --
> Thank you,
> Dmitri Pal
>
> Sr. Engineering Manager for IdM portfolio
> Red Hat Inc.
>
>
> -------------------------------
> Looking to carve out IT costs?
> www.redhat.com/carveoutcosts/ <http://www.redhat.com/carveoutcosts/>
>
>
>
>
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-***@redhat.com <mailto:Freeipa-***@redhat.com>
> https://www.redhat.com/mailman/listinfo/freeipa-users
>
>
>
>
> --
> Thank you,
> Dmitri Pal
>
> Sr. Engineering Manager for IdM portfolio
> Red Hat Inc.
>
>
> -------------------------------
> Looking to carve out IT costs?
> www.redhat.com/carveoutcosts/ <http://www.redhat.com/carveoutcosts/>
>
>


--
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
Macklin, Jason
2012-10-16 15:30:52 UTC
Permalink
Working user:

[***@dbduwdu062 log]$ sudo -l
LDAP Config Summary
===================
uri ldap://dbduvdu145.dbr.roche.com
ldap_version 3
sudoers_base ou=SUDOers,dc=dbr,dc=roche,dc=com
binddn uid=sudo,cn=sysaccounts,cn=etc,dc=dbr,dc=roche,dc=com
bindpw Roche454
bind_timelimit 5000
timelimit 15
ssl start_tls
tls_checkpeer (yes)
tls_cacertfile /etc/ipa/ca.crt
===================
sudo: ldap_set_option: debug -> 0
sudo: ldap_set_option: tls_checkpeer -> 1
sudo: ldap_set_option: tls_cacertfile -> /etc/ipa/ca.crt
sudo: ldap_set_option: tls_cacert -> /etc/ipa/ca.crt
sudo: ldap_initialize(ld, ldap://dbduvdu145.dbr.roche.com)
sudo: ldap_set_option: ldap_version -> 3
sudo: ldap_set_option: timelimit -> 15
sudo: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT, 5)
sudo: ldap_start_tls_s() ok
sudo: ldap_sasl_bind_s() ok
sudo: no default options found in ou=SUDOers,dc=dbr,dc=roche,dc=com
sudo: ldap sudoHost 'ALL' ... MATCH!
sudo: user_matches=1
sudo: host_matches=1
sudo: sudo_ldap_lookup(52)=0x82
Matching Defaults entries for jmacklin on this host:
requiretty, !visiblepw, always_set_home, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS", env_keep+="MAIL PS1
PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY
LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin

sudo: ldap search '(|(sudoUser=jmacklin)(sudoUser=%jmacklin)(sudoUser=%dbr)(sudoUser=%admins)(sudoUser=ALL))'
sudo: ldap sudoHost 'ALL' ... MATCH!
sudo: ldap search 'sudoUser=+*'
User jmacklin may run the following commands on this host:
(root) ALL

Non-working user:

Rule name: test4
Enabled: TRUE
Command category: all
Users: asteinfeld
Hosts: dbduwdu062.some.domain.com

LDAP Config Summary
===================
uri ldap://dbduvdu145.dbr.roche.com
ldap_version 3
sudoers_base ou=SUDOers,dc=dbr,dc=roche,dc=com
binddn uid=sudo,cn=sysaccounts,cn=etc,dc=dbr,dc=roche,dc=com
bindpw Roche454
bind_timelimit 5000
timelimit 15
ssl start_tls
tls_checkpeer (yes)
tls_cacertfile /etc/ipa/ca.crt
===================
sudo: ldap_set_option: debug -> 0
sudo: ldap_set_option: tls_checkpeer -> 1
sudo: ldap_set_option: tls_cacertfile -> /etc/ipa/ca.crt
sudo: ldap_set_option: tls_cacert -> /etc/ipa/ca.crt
sudo: ldap_initialize(ld, ldap://dbduvdu145.dbr.roche.com)
sudo: ldap_set_option: ldap_version -> 3
sudo: ldap_set_option: timelimit -> 15
sudo: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT, 5)
sudo: ldap_start_tls_s() ok
sudo: ldap_sasl_bind_s() ok
sudo: no default options found in ou=SUDOers,dc=dbr,dc=roche,dc=com
sudo: ldap sudoHost 'dbduwdu062.dbr.roche.com' ... not
sudo: user_matches=1
sudo: host_matches=0
sudo: sudo_ldap_lookup(52)=0x84
[sudo] password for asteinfeld:
Sorry, user asteinfeld may not run sudo on dbduwdu062.

Cheers,
Jason
From: Dmitri Pal [mailto:***@redhat.com]
Sent: Tuesday, October 16, 2012 11:22 AM
To: Macklin, Jason {DASB~Branford}
Cc: freeipa-***@redhat.com
Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.

On 10/16/2012 11:09 AM, Macklin, Jason wrote:
Dmitri,

I will give you everything I've got. If I can provide something else, let me know!

Working User:

Sudo debug output:

[***@dbduwdu062 log]$ sudo -l
sudo: ldap_set_option: debug -> 0
sudo: ldap_set_option: tls_checkpeer -> 1
sudo: ldap_set_option: tls_cacertfile -> /etc/ipa/ca.crt
sudo: ldap_set_option: tls_cacert -> /etc/ipa/ca.crt
sudo: ldap_set_option: ldap_version -> 3
sudo: ldap_set_option: timelimit -> 15
sudo: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT, 5)
sudo: ldap_start_tls_s() ok
sudo: ldap_sasl_bind_s() ok
sudo: no default options found in ou=SUDOers,dc=dbr,dc=roche,dc=com
sudo: user_matches=1
sudo: host_matches=1
sudo: sudo_ldap_lookup(52)=0x82
[sudo] password for jmacklin:
Matching Defaults entries for jmacklin on this host:
requiretty, !visiblepw, always_set_home, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS", env_keep+="MAIL PS1
PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY
LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin

sudo: ldap search '(|(sudoUser=jmacklin)(sudoUser=%jmacklin)(sudoUser=%dbr)(sudoUser=%admins)(sudoUser=ALL))'
sudo: ldap search 'sudoUser=+*'
User jmacklin may run the following commands on this host:
(root) ALL

/var/log/secure output:

Oct 16 11:00:03 dbduwdu062 sudo: pam_unix(sudo:auth): authentication failure; logname=jmacklin uid=0 euid=0 tty=/dev/pts/1 ruser=jmacklin rhost= user=jmacklin
Oct 16 11:00:04 dbduwdu062 sudo: pam_sss(sudo:auth): authentication success; logname=jmacklin uid=0 euid=0 tty=/dev/pts/1 ruser=jmacklin rhost= user=jmacklin
Oct 16 11:00:04 dbduwdu062 sudo: jmacklin : TTY=pts/1 ; PWD=/var/log ; USER=root ; COMMAND=list

Non-working user:

Sudo debug output:

[***@dbduwdu062 ~]$ sudo -l
sudo: ldap_set_option: debug -> 0
sudo: ldap_set_option: tls_checkpeer -> 1
sudo: ldap_set_option: tls_cacertfile -> /etc/ipa/ca.crt
sudo: ldap_set_option: tls_cacert -> /etc/ipa/ca.crt
sudo: ldap_set_option: ldap_version -> 3
sudo: ldap_set_option: timelimit -> 15
sudo: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT, 5)
sudo: ldap_start_tls_s() ok
sudo: ldap_sasl_bind_s() ok
sudo: no default options found in ou=SUDOers,dc=dbr,dc=domain,dc=com
sudo: user_matches=1
sudo: host_matches=0
sudo: sudo_ldap_lookup(52)=0x84
[sudo] password for asteinfeld:
Sorry, user asteinfeld may not run sudo on dbduwdu062

/var/log/secure output:

Oct 16 11:05:34 dbduwdu062 sudo: pam_unix(sudo:auth): authentication failure; logname=asteinfeld uid=0 euid=0 tty=/dev/pts/3 ruser=asteinfeld rhost= user=asteinfeld
Oct 16 11:05:35 dbduwdu062 sudo: pam_sss(sudo:auth): authentication success; logname=asteinfeld uid=0 euid=0 tty=/dev/pts/3 ruser=asteinfeld rhost= user=asteinfeld
Oct 16 11:05:35 dbduwdu062 sudo: asteinfeld : command not allowed ; TTY=pts/3 ; PWD=/home2/asteinfeld ; USER=root ; COMMAND=list

Cheers.
Jason


Please set sudoers_debug 2

http://www.doxer.org/learn-linux/modify-sudoers_debug-in-ldap-conf-to-debug-sudo-on-linux-and-solaris/




From: freeipa-users-***@redhat.com<mailto:freeipa-users-***@redhat.com> [mailto:freeipa-users-***@redhat.com] On Behalf Of Dmitri Pal
Sent: Tuesday, October 16, 2012 10:33 AM
To: freeipa-***@redhat.com<mailto:freeipa-***@redhat.com>
Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.

On 10/16/2012 10:05 AM, Macklin, Jason wrote:
When I become the user in question I see the following in the sssd log.

[ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule [test]

I think this is a sudo problem before anything else. For a user in which sudo works, host_matches = 1 always returns when debugging is on. For a user that does not work host_matches always equals 0 (zero).


Is there any way to see a more detailed debug log from sudo then? It should show what it is looking for and what it is getting back from the server.



I am open to troubleshooting the ldap configuration as I am not convinced that it is referencing the host properly. I enroll the clients using FQDN, but noticed that initially, domainname and nisdomainname qould return (none). Fixing these to show the correct domain did not change the behavior of the nodes though.

Thanks again!

Jason

From: freeipa-users-***@redhat.com<mailto:freeipa-users-***@redhat.com> [mailto:freeipa-users-***@redhat.com] On Behalf Of Dmitri Pal
Sent: Monday, October 15, 2012 5:58 PM
To: freeipa-***@redhat.com<mailto:freeipa-***@redhat.com>
Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.

On 10/15/2012 04:46 PM, Dmitri Pal wrote:
On 10/15/2012 04:34 PM, Macklin, Jason wrote:
Hi,

I apologize up front if this is obvious, but I'm having issues configuring sudo privileges.

I currently have an IPA server running FreeIPA 2.2 with sudo configured for our administrators on all hosts. This works fantastic! As soon as I attempt to configure a more specific sudo rule it does not work. In my troubleshooting, I have noticed that from the same host my admin level privileges work, but with another user account setup to just run one command, it fails. I have turned on sudo debugging and the only thing I can find that looks out of sorts is the following:

sudo: host_matches=0

As soon as I move the user account that is failing into the admin group it starts to work.

I have attempted every iteration of sudo configuration on the server that I can think of. I have setup HBAC and given that a shot as well. At this point I'm completely stumped and would appreciate any help that I can get!

What does sudo test return?

Yes I meant HBAC. I might confused you and myself so let us start over.

First we need to make sure that the authentication happens correctly so if HBAC is set to allow you should see in the SSSD log that access is granted. That will limit the problem to just SUDO. If you have the allow_all HBAC rule and no other rules then we can probably skip this step and move on to trying to solve the actual SUDO part.

So with SUDO one of the known issues is the long vs short hostname. Do you by any chance use a short host name for that host?
If names are FQDN the next step would be to use ldapsearch from the client and see what LDAP entries the server would return.





Thank you in advance for your assistance,
Jason






_______________________________________________

Freeipa-users mailing list

Freeipa-***@redhat.com<mailto:Freeipa-***@redhat.com>

https://www.redhat.com/mailman/listinfo/freeipa-users






--

Thank you,

Dmitri Pal



Sr. Engineering Manager for IdM portfolio

Red Hat Inc.





-------------------------------

Looking to carve out IT costs?

www.redhat.com/carveoutcosts/<http://www.redhat.com/carveoutcosts/>










_______________________________________________

Freeipa-users mailing list

Freeipa-***@redhat.com<mailto:Freeipa-***@redhat.com>

https://www.redhat.com/mailman/listinfo/freeipa-users






--

Thank you,

Dmitri Pal



Sr. Engineering Manager for IdM portfolio

Red Hat Inc.





-------------------------------

Looking to carve out IT costs?

www.redhat.com/carveoutcosts/<http://www.redhat.com/carveoutcosts/>









_______________________________________________

Freeipa-users mailing list

Freeipa-***@redhat.com<mailto:Freeipa-***@redhat.com>

https://www.redhat.com/mailman/listinfo/freeipa-users





--

Thank you,

Dmitri Pal



Sr. Engineering Manager for IdM portfolio

Red Hat Inc.





-------------------------------

Looking to carve out IT costs?

www.redhat.com/carveoutcosts/<http://www.redhat.com/carveoutcosts/>








--

Thank you,

Dmitri Pal



Sr. Engineering Manager for IdM portfolio

Red Hat Inc.





-------------------------------

Looking to carve out IT costs?

www.redhat.com/carveoutcosts/<http://www.redhat.com/carveoutcosts/>
Dmitri Pal
2012-10-16 16:09:50 UTC
Permalink
On 10/16/2012 11:30 AM, Macklin, Jason wrote:
>
> *Working user:*
>
> * *
>
> [***@dbduwdu062 log]$ sudo -l
>
> LDAP Config Summary
>
> ===================
>
> uri ldap://dbduvdu145.dbr.roche.com
>
> ldap_version 3
>
> sudoers_base ou=SUDOers,dc=dbr,dc=roche,dc=com
>
> binddn uid=sudo,cn=sysaccounts,cn=etc,dc=dbr,dc=roche,dc=com
>
> bindpw Roche454
>
> bind_timelimit 5000
>
> timelimit 15
>
> ssl start_tls
>
> tls_checkpeer (yes)
>
> tls_cacertfile /etc/ipa/ca.crt
>
> ===================
>
> sudo: ldap_set_option: debug -> 0
>
> sudo: ldap_set_option: tls_checkpeer -> 1
>
> sudo: ldap_set_option: tls_cacertfile -> /etc/ipa/ca.crt
>
> sudo: ldap_set_option: tls_cacert -> /etc/ipa/ca.crt
>
> sudo: ldap_initialize(ld, ldap://dbduvdu145.dbr.roche.com)
>
> sudo: ldap_set_option: ldap_version -> 3
>
> sudo: ldap_set_option: timelimit -> 15
>
> sudo: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT, 5)
>
> sudo: ldap_start_tls_s() ok
>
> sudo: ldap_sasl_bind_s() ok
>
> sudo: no default options found in ou=SUDOers,dc=dbr,dc=roche,dc=com
>
> sudo: ldap sudoHost 'ALL' ... MATCH!
>
> sudo: user_matches=1
>
> sudo: host_matches=1
>
> sudo: sudo_ldap_lookup(52)=0x82
>
> Matching Defaults entries for jmacklin on this host:
>
> requiretty, !visiblepw, always_set_home, env_reset,
> env_keep="COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS",
> env_keep+="MAIL PS1
>
> PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
> env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
> env_keep+="LC_MONETARY
>
> LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME
> LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
>
> secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin
>
>
>
> sudo: ldap search
> '(|(sudoUser=jmacklin)(sudoUser=%jmacklin)(sudoUser=%dbr)(sudoUser=%admins)(sudoUser=ALL))'
>
> sudo: ldap sudoHost 'ALL' ... MATCH!
>
> sudo: ldap search 'sudoUser=+*'
>
> User jmacklin may run the following commands on this host:
>
> (root) ALL
>
>
>
> *Non-working user:*
>
> * *
>
> * Rule name: test4*
>
> * Enabled: TRUE*
>
> * Command category: all*
>
> * Users: asteinfeld*
>
> * Hosts: dbduwdu062.some.domain.com*
>
>
>
> LDAP Config Summary
>
> ===================
>
> uri ldap://dbduvdu145.dbr.roche.com
>
> ldap_version 3
>
> sudoers_base ou=SUDOers,dc=dbr,dc=roche,dc=com
>
> binddn uid=sudo,cn=sysaccounts,cn=etc,dc=dbr,dc=roche,dc=com
>
> bindpw Roche454
>
> bind_timelimit 5000
>
> timelimit 15
>
> ssl start_tls
>
> tls_checkpeer (yes)
>
> tls_cacertfile /etc/ipa/ca.crt
>
> ===================
>
> sudo: ldap_set_option: debug -> 0
>
> sudo: ldap_set_option: tls_checkpeer -> 1
>
> sudo: ldap_set_option: tls_cacertfile -> /etc/ipa/ca.crt
>
> sudo: ldap_set_option: tls_cacert -> /etc/ipa/ca.crt
>
> sudo: ldap_initialize(ld, ldap://dbduvdu145.dbr.roche.com)
>
> sudo: ldap_set_option: ldap_version -> 3
>
> sudo: ldap_set_option: timelimit -> 15
>
> sudo: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT, 5)
>
> sudo: ldap_start_tls_s() ok
>
> sudo: ldap_sasl_bind_s() ok
>
> sudo: no default options found in ou=SUDOers,dc=dbr,dc=roche,dc=com
>
> sudo: ldap sudoHost 'dbduwdu062.dbr.roche.com' ... not
>

So this is the name the sudo client tries to match and it does not seem
to find any hosts.
Now we need to look at the ou=SUDOers,dc=dbr,dc=roche,dc=com with
ldapsearch and see the SUDO rules that are exposed by the server and
match them visually to the current host.


> sudo: user_matches=1
>
> sudo: host_matches=0
>
> sudo: sudo_ldap_lookup(52)=0x84
>
> [sudo] password for asteinfeld:
>
> Sorry, user asteinfeld may not run sudo on dbduwdu062.
>
>
>
> Cheers,
>
> Jason
>
> *From:*Dmitri Pal [mailto:***@redhat.com]
> *Sent:* Tuesday, October 16, 2012 11:22 AM
> *To:* Macklin, Jason {DASB~Branford}
> *Cc:* freeipa-***@redhat.com
> *Subject:* Re: [Freeipa-users] Sudo works for full access, but not on
> a per command or host level.
>
>
>
> On 10/16/2012 11:09 AM, Macklin, Jason wrote:
>
> Dmitri,
>
>
>
> I will give you everything I've got. If I can provide something else,
> let me know!
>
>
>
> *Working User:*
>
>
>
> *Sudo debug output:*
>
>
>
> [***@dbduwdu062 log]$ sudo -l
>
> sudo: ldap_set_option: debug -> 0
>
> sudo: ldap_set_option: tls_checkpeer -> 1
>
> sudo: ldap_set_option: tls_cacertfile -> /etc/ipa/ca.crt
>
> sudo: ldap_set_option: tls_cacert -> /etc/ipa/ca.crt
>
> sudo: ldap_set_option: ldap_version -> 3
>
> sudo: ldap_set_option: timelimit -> 15
>
> sudo: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT, 5)
>
> sudo: ldap_start_tls_s() ok
>
> sudo: ldap_sasl_bind_s() ok
>
> sudo: no default options found in ou=SUDOers,dc=dbr,dc=roche,dc=com
>
> sudo: user_matches=1
>
> sudo: host_matches=1
>
> sudo: sudo_ldap_lookup(52)=0x82
>
> [sudo] password for jmacklin:
>
> Matching Defaults entries for jmacklin on this host:
>
> requiretty, !visiblepw, always_set_home, env_reset,
> env_keep="COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS",
> env_keep+="MAIL PS1
>
> PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
> env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
> env_keep+="LC_MONETARY
>
> LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME
> LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
>
> secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin
>
>
>
> sudo: ldap search
> '(|(sudoUser=jmacklin)(sudoUser=%jmacklin)(sudoUser=%dbr)(sudoUser=%admins)(sudoUser=ALL))'
>
> sudo: ldap search 'sudoUser=+*'
>
> User jmacklin may run the following commands on this host:
>
> (root) ALL
>
>
>
> */var/log/secure output:*
>
>
>
> Oct 16 11:00:03 dbduwdu062 sudo: pam_unix(sudo:auth): authentication
> failure; logname=jmacklin uid=0 euid=0 tty=/dev/pts/1 ruser=jmacklin
> rhost= user=jmacklin
>
> Oct 16 11:00:04 dbduwdu062 sudo: pam_sss(sudo:auth): authentication
> success; logname=jmacklin uid=0 euid=0 tty=/dev/pts/1 ruser=jmacklin
> rhost= user=jmacklin
>
> Oct 16 11:00:04 dbduwdu062 sudo: jmacklin : TTY=pts/1 ; PWD=/var/log ;
> USER=root ; COMMAND=list
>
>
>
> *Non-working user:*
>
> * *
>
> *Sudo debug output:*
>
> * *
>
> [***@dbduwdu062 ~]$ sudo -l
>
> sudo: ldap_set_option: debug -> 0
>
> sudo: ldap_set_option: tls_checkpeer -> 1
>
> sudo: ldap_set_option: tls_cacertfile -> /etc/ipa/ca.crt
>
> sudo: ldap_set_option: tls_cacert -> /etc/ipa/ca.crt
>
> sudo: ldap_set_option: ldap_version -> 3
>
> sudo: ldap_set_option: timelimit -> 15
>
> sudo: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT, 5)
>
> sudo: ldap_start_tls_s() ok
>
> sudo: ldap_sasl_bind_s() ok
>
> sudo: no default options found in ou=SUDOers,dc=dbr,dc=domain,dc=com
>
> sudo: user_matches=1
>
> sudo: host_matches=0
>
> sudo: sudo_ldap_lookup(52)=0x84
>
> [sudo] password for asteinfeld:
>
> Sorry, user asteinfeld may not run sudo on dbduwdu062
>
>
>
> */var/log/secure output:*
>
> * *
>
> Oct 16 11:05:34 dbduwdu062 sudo: pam_unix(sudo:auth): authentication
> failure; logname=asteinfeld uid=0 euid=0 tty=/dev/pts/3
> ruser=asteinfeld rhost= user=asteinfeld
>
> Oct 16 11:05:35 dbduwdu062 sudo: pam_sss(sudo:auth): authentication
> success; logname=asteinfeld uid=0 euid=0 tty=/dev/pts/3
> ruser=asteinfeld rhost= user=asteinfeld
>
> Oct 16 11:05:35 dbduwdu062 sudo: asteinfeld : command not allowed ;
> TTY=pts/3 ; PWD=/home2/asteinfeld ; USER=root ; COMMAND=list
>
>
>
> Cheers.
>
> Jason
>
>
>
> Please set sudoers_debug 2
>
> http://www.doxer.org/learn-linux/modify-sudoers_debug-in-ldap-conf-to-debug-sudo-on-linux-and-solaris/
>
>
>
>
>
>
>
> *From:*freeipa-users-***@redhat.com
> <mailto:freeipa-users-***@redhat.com>
> [mailto:freeipa-users-***@redhat.com] *On Behalf Of *Dmitri Pal
> *Sent:* Tuesday, October 16, 2012 10:33 AM
> *To:* freeipa-***@redhat.com <mailto:freeipa-***@redhat.com>
> *Subject:* Re: [Freeipa-users] Sudo works for full access, but not on
> a per command or host level.
>
>
>
> On 10/16/2012 10:05 AM, Macklin, Jason wrote:
>
> When I become the user in question I see the following in the sssd log.
>
>
>
> [ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC
> rule [test]
>
>
>
> I think this is a sudo problem before anything else. For a user in
> which sudo works, host_matches = 1 always returns when debugging is
> on. For a user that does not work host_matches always equals 0 (zero).
>
>
>
>
> Is there any way to see a more detailed debug log from sudo then? It
> should show what it is looking for and what it is getting back from
> the server.
>
>
>
> I am open to troubleshooting the ldap configuration as I am not
> convinced that it is referencing the host properly. I enroll the
> clients using FQDN, but noticed that initially, domainname and
> nisdomainname qould return (none). Fixing these to show the correct
> domain did not change the behavior of the nodes though.
>
>
>
> Thanks again!
>
>
>
> Jason
>
>
>
> *From:*freeipa-users-***@redhat.com
> <mailto:freeipa-users-***@redhat.com>
> [mailto:freeipa-users-***@redhat.com] *On Behalf Of *Dmitri Pal
> *Sent:* Monday, October 15, 2012 5:58 PM
> *To:* freeipa-***@redhat.com <mailto:freeipa-***@redhat.com>
> *Subject:* Re: [Freeipa-users] Sudo works for full access, but not on
> a per command or host level.
>
>
>
> On 10/15/2012 04:46 PM, Dmitri Pal wrote:
>
> On 10/15/2012 04:34 PM, Macklin, Jason wrote:
>
> Hi,
>
>
>
> I apologize up front if this is obvious, but I'm having issues
> configuring sudo privileges.
>
>
>
> I currently have an IPA server running FreeIPA 2.2 with sudo
> configured for our administrators on all hosts. This works
> fantastic! As soon as I attempt to configure a more specific sudo
> rule it does not work. In my troubleshooting, I have noticed that
> from the same host my admin level privileges work, but with another
> user account setup to just run one command, it fails. I have turned
> on sudo debugging and the only thing I can find that looks out of
> sorts is the following:
>
>
>
> sudo: host_matches=0
>
>
>
> As soon as I move the user account that is failing into the admin
> group it starts to work.
>
>
>
> I have attempted every iteration of sudo configuration on the server
> that I can think of. I have setup HBAC and given that a shot as
> well. At this point I'm completely stumped and would appreciate any
> help that I can get!
>
>
> What does sudo test return?
>
>
> Yes I meant HBAC. I might confused you and myself so let us start over.
>
> First we need to make sure that the authentication happens correctly
> so if HBAC is set to allow you should see in the SSSD log that access
> is granted. That will limit the problem to just SUDO. If you have the
> allow_all HBAC rule and no other rules then we can probably skip this
> step and move on to trying to solve the actual SUDO part.
>
> So with SUDO one of the known issues is the long vs short hostname. Do
> you by any chance use a short host name for that host?
> If names are FQDN the next step would be to use ldapsearch from the
> client and see what LDAP entries the server would return.
>
>
>
>
>
>
> Thank you in advance for your assistance,
>
> Jason
>
>
>
>
>
>
> _______________________________________________
>
> Freeipa-users mailing list
>
> Freeipa-***@redhat.com <mailto:Freeipa-***@redhat.com>
>
> https://www.redhat.com/mailman/listinfo/freeipa-users
>
>
>
>
>
>
> --
> Thank you,
> Dmitri Pal
>
> Sr. Engineering Manager for IdM portfolio
> Red Hat Inc.
>
>
> -------------------------------
> Looking to carve out IT costs?
> www.redhat.com/carveoutcosts/ <http://www.redhat.com/carveoutcosts/>
>
>
>
>
>
>
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-***@redhat.com <mailto:Freeipa-***@redhat.com>
> https://www.redhat.com/mailman/listinfo/freeipa-users
>
>
>
>
>
>
> --
> Thank you,
> Dmitri Pal
>
> Sr. Engineering Manager for IdM portfolio
> Red Hat Inc.
>
>
> -------------------------------
> Looking to carve out IT costs?
> www.redhat.com/carveoutcosts/ <http://www.redhat.com/carveoutcosts/>
>
>
>
>
>
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-***@redhat.com <mailto:Freeipa-***@redhat.com>
> https://www.redhat.com/mailman/listinfo/freeipa-users
>
>
>
>
>
> --
> Thank you,
> Dmitri Pal
>
> Sr. Engineering Manager for IdM portfolio
> Red Hat Inc.
>
>
> -------------------------------
> Looking to carve out IT costs?
> www.redhat.com/carveoutcosts/ <http://www.redhat.com/carveoutcosts/>
>
>
>
>
>
>
> --
> Thank you,
> Dmitri Pal
>
> Sr. Engineering Manager for IdM portfolio
> Red Hat Inc.
>
>
> -------------------------------
> Looking to carve out IT costs?
> www.redhat.com/carveoutcosts/ <http://www.redhat.com/carveoutcosts/>
>
>


--
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
Jakub Hrozek
2012-10-16 17:05:19 UTC
Permalink
On Tue, Oct 16, 2012 at 12:09:50PM -0400, Dmitri Pal wrote:
> > sudo: ldap sudoHost 'dbduwdu062.dbr.roche.com' ... not
> >
>
> So this is the name the sudo client tries to match and it does not seem
> to find any hosts.
> Now we need to look at the ou=SUDOers,dc=dbr,dc=roche,dc=com with
> ldapsearch and see the SUDO rules that are exposed by the server and
> match them visually to the current host.
>

Can you also check if the host name on the broken host is set correctly
and resolves fine?
Macklin, Jason
2012-10-16 17:57:51 UTC
Permalink
Yes, resolution works correctly at both the host and the freeIPA server.

Dmitri,

I am still quite new to LDAP so I'm not sure exactly what I should be looking for when running ldapsearch.

The attempts that I have made have been less then fruitful though... examples follow

/usr/bin/ldapsearch -I -H ldap://dbduvdu145.dbr.roche.com "ou=SUDOers,dc=dbr,dc=roche,dc=com"SASL/EXTERNAL authentication started
ldap_sasl_interactive_bind_s: Unknown authentication method (-6)
additional info: SASL(-4): no mechanism available:

This sort of return occurs for either working or non-working users both!

As I am new to ldap... is there a specific ldapsearch command/option I should be using?
Rob Crittenden
2012-10-16 21:44:35 UTC
Permalink
Macklin, Jason wrote:
> Yes, resolution works correctly at both the host and the freeIPA server.
>
> Dmitri,
>
> I am still quite new to LDAP so I'm not sure exactly what I should be looking for when running ldapsearch.
>
> The attempts that I have made have been less then fruitful though... examples follow
>
> /usr/bin/ldapsearch -I -H ldap://dbduvdu145.dbr.roche.com "ou=SUDOers,dc=dbr,dc=roche,dc=com"SASL/EXTERNAL authentication started
> ldap_sasl_interactive_bind_s: Unknown authentication method (-6)
> additional info: SASL(-4): no mechanism available:
>
> This sort of return occurs for either working or non-working users both!
>
> As I am new to ldap... is there a specific ldapsearch command/option I should be using?

You want to be authenticated to search the sudo data, so do something like:

$ kinit admin (or some user)
$ ldapsearch -Y GSSAPI ...

rob
JR Aquino
2012-10-17 03:58:40 UTC
Permalink
This post might be inappropriate. Click to display it.
Macklin, Jason
2012-10-17 13:26:55 UTC
Permalink
Okay,

Rule name: test4
Enabled: TRUE
Command category: all
Users: asteinfeld
Hosts: dbduwdu062.dbr.roche.com
Host Groups: tempsudo

Client dbduwdu062 is matched in the rule by both the hosts and groups entry.

/etc/nsswitch.conf has:

Netgroups: files sss

Getent netgroup tempsudo returns:

[***@dbduwdu062 Desktop]$ getent netgroup tempsudo
tempsudo (dbduwdu063.dbr.roche.com, -, dbr.roche.com) (dbduwdu062.dbr.roche.com, -, dbr.roche.com)

To the previous ldapsearch request:

[***@dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com "ou=SUDOers,dc=dbr,dc=roche,dc=com"
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Server is unwilling to perform (53)
additional info: Entry permanently locked.

I am still scratching my head on this one...

Cheers,
Jason

If you look closely, the reason that your admin works is because it appears to be matching a sudo rule who has the "ALL" hosts value set.

When you run the non working user, it is attempting to match the hostname/hostgroup to the rule and fails to do so.

Try this. Type: getent netgroup hostgroupname <- your host's hostgroup goes there.

^ that command should return all of the hosts in your hostgroup. If it does not, then check /etc/nsswitch.conf and make sure that netgroup is set to use sss.

You will also need to make sure that the output of: domainname or nisdomainname matches your expected domain.

Let me know how things look after trying that.
Rich Megginson
2012-10-17 15:53:07 UTC
Permalink
On 10/17/2012 07:26 AM, Macklin, Jason wrote:
> Okay,
>
> Rule name: test4
> Enabled: TRUE
> Command category: all
> Users: asteinfeld
> Hosts: dbduwdu062.dbr.roche.com
> Host Groups: tempsudo
>
> Client dbduwdu062 is matched in the rule by both the hosts and groups entry.
>
> /etc/nsswitch.conf has:
>
> Netgroups: files sss
>
> Getent netgroup tempsudo returns:
>
> [***@dbduwdu062 Desktop]$ getent netgroup tempsudo
> tempsudo (dbduwdu063.dbr.roche.com, -, dbr.roche.com) (dbduwdu062.dbr.roche.com, -, dbr.roche.com)
>
> To the previous ldapsearch request:
>
> [***@dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com "ou=SUDOers,dc=dbr,dc=roche,dc=com"
> SASL/GSSAPI authentication started
> ldap_sasl_interactive_bind_s: Server is unwilling to perform (53)
> additional info: Entry permanently locked.
>
> I am still scratching my head on this one...

This means you cannot search using your kerberos ticket because the
corresponding entry is locked. Try using directory manager:

ldapsearch -x -D "cn=directory manager" -W -H
ldap://dbduvdu145.dbr.roche.com "ou=SUDOers,dc=dbr,dc=roche,dc=com"


>
> Cheers,
> Jason
>
> If you look closely, the reason that your admin works is because it appears to be matching a sudo rule who has the "ALL" hosts value set.
>
> When you run the non working user, it is attempting to match the hostname/hostgroup to the rule and fails to do so.
>
> Try this. Type: getent netgroup hostgroupname<- your host's hostgroup goes there.
>
> ^ that command should return all of the hosts in your hostgroup. If it does not, then check /etc/nsswitch.conf and make sure that netgroup is set to use sss.
>
> You will also need to make sure that the output of: domainname or nisdomainname matches your expected domain.
>
> Let me know how things look after trying that.
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-***@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
Simo Sorce
2012-10-17 16:46:59 UTC
Permalink
On Wed, 2012-10-17 at 09:53 -0600, Rich Megginson wrote:
> On 10/17/2012 07:26 AM, Macklin, Jason wrote:
> > Okay,
> >
> > Rule name: test4
> > Enabled: TRUE
> > Command category: all
> > Users: asteinfeld
> > Hosts: dbduwdu062.dbr.roche.com
> > Host Groups: tempsudo
> >
> > Client dbduwdu062 is matched in the rule by both the hosts and groups entry.
> >
> > /etc/nsswitch.conf has:
> >
> > Netgroups: files sss
> >
> > Getent netgroup tempsudo returns:
> >
> > [***@dbduwdu062 Desktop]$ getent netgroup tempsudo
> > tempsudo (dbduwdu063.dbr.roche.com, -, dbr.roche.com) (dbduwdu062.dbr.roche.com, -, dbr.roche.com)
> >
> > To the previous ldapsearch request:
> >
> > [***@dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com "ou=SUDOers,dc=dbr,dc=roche,dc=com"
> > SASL/GSSAPI authentication started
> > ldap_sasl_interactive_bind_s: Server is unwilling to perform (53)
> > additional info: Entry permanently locked.
> >
> > I am still scratching my head on this one...
>
> This means you cannot search using your kerberos ticket because the
> corresponding entry is locked. Try using directory manager:
>
> ldapsearch -x -D "cn=directory manager" -W -H
> ldap://dbduvdu145.dbr.roche.com "ou=SUDOers,dc=dbr,dc=roche,dc=com"
>

This sounds very wrong.

If the user had a kerberos ticket in the first place it meant it
successfully authenticated.

If no krb ticket was available GSSAPI would have not started at all.

This look like some odd error in directory server failing to recognize
valid users ?

Simo.

--
Simo Sorce * Red Hat, Inc * New York
Rich Megginson
2012-10-17 16:54:16 UTC
Permalink
On 10/17/2012 10:46 AM, Simo Sorce wrote:
> On Wed, 2012-10-17 at 09:53 -0600, Rich Megginson wrote:
>> On 10/17/2012 07:26 AM, Macklin, Jason wrote:
>>> Okay,
>>>
>>> Rule name: test4
>>> Enabled: TRUE
>>> Command category: all
>>> Users: asteinfeld
>>> Hosts: dbduwdu062.dbr.roche.com
>>> Host Groups: tempsudo
>>>
>>> Client dbduwdu062 is matched in the rule by both the hosts and groups entry.
>>>
>>> /etc/nsswitch.conf has:
>>>
>>> Netgroups: files sss
>>>
>>> Getent netgroup tempsudo returns:
>>>
>>> [***@dbduwdu062 Desktop]$ getent netgroup tempsudo
>>> tempsudo (dbduwdu063.dbr.roche.com, -, dbr.roche.com) (dbduwdu062.dbr.roche.com, -, dbr.roche.com)
>>>
>>> To the previous ldapsearch request:
>>>
>>> [***@dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com "ou=SUDOers,dc=dbr,dc=roche,dc=com"
>>> SASL/GSSAPI authentication started
>>> ldap_sasl_interactive_bind_s: Server is unwilling to perform (53)
>>> additional info: Entry permanently locked.
>>>
>>> I am still scratching my head on this one...
>> This means you cannot search using your kerberos ticket because the
>> corresponding entry is locked. Try using directory manager:
>>
>> ldapsearch -x -D "cn=directory manager" -W -H
>> ldap://dbduvdu145.dbr.roche.com "ou=SUDOers,dc=dbr,dc=roche,dc=com"
>>
> This sounds very wrong.
>
> If the user had a kerberos ticket in the first place it meant it
> successfully authenticated.
>
> If no krb ticket was available GSSAPI would have not started at all.
>
> This look like some odd error in directory server failing to recognize
> valid users ?
Not sure what's going on. Looking at the code in ipa_lockout.c:
lockout_duration = slapi_entry_attr_get_uint(policy_entry,
"krbPwdLockoutDuration");
if (lockout_duration == 0) {
errstr = "Entry permanently locked.\n";
ret = LDAP_UNWILLING_TO_PERFORM;
goto done;
}

This means either krbPwdLockoutDuration does not exist at all, or does
exist and has a value of 0.

Can you do an ldapsearch of your entry like this:

ldapsearch -xLLL -D "cn=directory manager" -W uid=youruserid \*
krbPwdLockoutDuration
?
>
> Simo.
>
Macklin, Jason
2012-10-17 17:13:22 UTC
Permalink
None of my users have an LDAP password being requested by running that command (except the admin user).

Does each user account require an ldap account to go along with their login account? I just get the following over and over no matter which account I switch in the command...

[***@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=admin \* krbPwdLockoutDuration ?
Enter LDAP Password:
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
[***@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=asteinfeld \* krbPwdLockoutDuration ?
Enter LDAP Password:
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
[***@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=jmacklin \* krbPwdLockoutDuration ?
Enter LDAP Password:
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
Rich Megginson
2012-10-17 17:15:06 UTC
Permalink
On 10/17/2012 11:13 AM, Macklin, Jason wrote:
> None of my users have an LDAP password being requested by running that command (except the admin user).
>
> Does each user account require an ldap account to go along with their login account? I just get the following over and over no matter which account I switch in the command...
>
> [***@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=admin \* krbPwdLockoutDuration ?
> Enter LDAP Password:
> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
> [***@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=asteinfeld \* krbPwdLockoutDuration ?
> Enter LDAP Password:
> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
> [***@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=jmacklin \* krbPwdLockoutDuration ?
> Enter LDAP Password:
> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
You have to specify which server to talk to using the -H
ldap://fqdn.of.host option.
Macklin, Jason
2012-10-17 17:21:39 UTC
Permalink
ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W uid=asteinfeld \* krbPwdLockoutDuration ?
Enter LDAP Password:
ldap_bind: Invalid credentials (49)

I know this user password because I reset it for the purpose of troubleshooting this issue with that account. I also get the same response when I use the admin account of my own account.

-----Original Message-----
From: Rich Megginson [mailto:***@redhat.com]
Sent: Wednesday, October 17, 2012 1:15 PM
To: Macklin, Jason {DASB~Branford}
Cc: ***@redhat.com; freeipa-***@redhat.com
Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.

On 10/17/2012 11:13 AM, Macklin, Jason wrote:
> None of my users have an LDAP password being requested by running that command (except the admin user).
>
> Does each user account require an ldap account to go along with their login account? I just get the following over and over no matter which account I switch in the command...
>
> [***@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=admin \* krbPwdLockoutDuration ?
> Enter LDAP Password:
> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
> [***@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=asteinfeld \* krbPwdLockoutDuration ?
> Enter LDAP Password:
> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
> [***@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=jmacklin \* krbPwdLockoutDuration ?
> Enter LDAP Password:
> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
You have to specify which server to talk to using the -H ldap://fqdn.of.host option.
Rob Crittenden
2012-10-17 17:37:19 UTC
Permalink
Macklin, Jason wrote:
> ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W uid=asteinfeld \* krbPwdLockoutDuration ?
> Enter LDAP Password:
> ldap_bind: Invalid credentials (49)
>
> I know this user password because I reset it for the purpose of troubleshooting this issue with that account. I also get the same response when I use the admin account of my own account.

You use the password of the user you are binding as, in this case the
directory manager.

rob

>
> -----Original Message-----
> From: Rich Megginson [mailto:***@redhat.com]
> Sent: Wednesday, October 17, 2012 1:15 PM
> To: Macklin, Jason {DASB~Branford}
> Cc: ***@redhat.com; freeipa-***@redhat.com
> Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
>
> On 10/17/2012 11:13 AM, Macklin, Jason wrote:
>> None of my users have an LDAP password being requested by running that command (except the admin user).
>>
>> Does each user account require an ldap account to go along with their login account? I just get the following over and over no matter which account I switch in the command...
>>
>> [***@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=admin \* krbPwdLockoutDuration ?
>> Enter LDAP Password:
>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
>> [***@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=asteinfeld \* krbPwdLockoutDuration ?
>> Enter LDAP Password:
>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
>> [***@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=jmacklin \* krbPwdLockoutDuration ?
>> Enter LDAP Password:
>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
> You have to specify which server to talk to using the -H ldap://fqdn.of.host option.
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-***@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>
Macklin, Jason
2012-10-17 17:51:30 UTC
Permalink
I assume that this iteration was with the correct credentials as it responds with something other then "Invalid Credentials"

ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W uid=asteinfeld \* krbPwdLockoutDuration ?
Enter LDAP Password:
No such object (32)

Working account returns same thing...

ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W uid=jmacklin \* krbPwdLockoutDuration ?
Enter LDAP Password:
No such object (32)

-----Original Message-----
From: Rob Crittenden [mailto:***@redhat.com]
Sent: Wednesday, October 17, 2012 1:37 PM
To: Macklin, Jason {DASB~Branford}
Cc: ***@redhat.com; freeipa-***@redhat.com
Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.

Macklin, Jason wrote:
> ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W uid=asteinfeld \* krbPwdLockoutDuration ?
> Enter LDAP Password:
> ldap_bind: Invalid credentials (49)
>
> I know this user password because I reset it for the purpose of troubleshooting this issue with that account. I also get the same response when I use the admin account of my own account.

You use the password of the user you are binding as, in this case the directory manager.

rob

>
> -----Original Message-----
> From: Rich Megginson [mailto:***@redhat.com]
> Sent: Wednesday, October 17, 2012 1:15 PM
> To: Macklin, Jason {DASB~Branford}
> Cc: ***@redhat.com; freeipa-***@redhat.com
> Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
>
> On 10/17/2012 11:13 AM, Macklin, Jason wrote:
>> None of my users have an LDAP password being requested by running that command (except the admin user).
>>
>> Does each user account require an ldap account to go along with their login account? I just get the following over and over no matter which account I switch in the command...
>>
>> [***@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=admin \* krbPwdLockoutDuration ?
>> Enter LDAP Password:
>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
>> [***@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=asteinfeld \* krbPwdLockoutDuration ?
>> Enter LDAP Password:
>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
>> [***@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=jmacklin \* krbPwdLockoutDuration ?
>> Enter LDAP Password:
>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
> You have to specify which server to talk to using the -H ldap://fqdn.of.host option.
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-***@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>
Rich Megginson
2012-10-17 18:05:37 UTC
Permalink
On 10/17/2012 11:51 AM, Macklin, Jason wrote:
> I assume that this iteration was with the correct credentials as it responds with something other then "Invalid Credentials"
>
> ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W uid=asteinfeld \* krbPwdLockoutDuration ?
> Enter LDAP Password:
> No such object (32)
>
> Working account returns same thing...
>
> ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W uid=jmacklin \* krbPwdLockoutDuration ?
> Enter LDAP Password:
> No such object (32)

Sorry, I though ipa would have configured your /etc/openldap/ldap.conf
with your base dn. Try this:

ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory
manager" -W -b "dc=dbr,dc=roche,dc=com" uid=jmacklin \*
>
> -----Original Message-----
> From: Rob Crittenden [mailto:***@redhat.com]
> Sent: Wednesday, October 17, 2012 1:37 PM
> To: Macklin, Jason {DASB~Branford}
> Cc: ***@redhat.com; freeipa-***@redhat.com
> Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
>
> Macklin, Jason wrote:
>> ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W uid=asteinfeld \* krbPwdLockoutDuration ?
>> Enter LDAP Password:
>> ldap_bind: Invalid credentials (49)
>>
>> I know this user password because I reset it for the purpose of troubleshooting this issue with that account. I also get the same response when I use the admin account of my own account.
> You use the password of the user you are binding as, in this case the directory manager.
>
> rob
>
>> -----Original Message-----
>> From: Rich Megginson [mailto:***@redhat.com]
>> Sent: Wednesday, October 17, 2012 1:15 PM
>> To: Macklin, Jason {DASB~Branford}
>> Cc: ***@redhat.com; freeipa-***@redhat.com
>> Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
>>
>> On 10/17/2012 11:13 AM, Macklin, Jason wrote:
>>> None of my users have an LDAP password being requested by running that command (except the admin user).
>>>
>>> Does each user account require an ldap account to go along with their login account? I just get the following over and over no matter which account I switch in the command...
>>>
>>> [***@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=admin \* krbPwdLockoutDuration ?
>>> Enter LDAP Password:
>>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
>>> [***@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=asteinfeld \* krbPwdLockoutDuration ?
>>> Enter LDAP Password:
>>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
>>> [***@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=jmacklin \* krbPwdLockoutDuration ?
>>> Enter LDAP Password:
>>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
>> You have to specify which server to talk to using the -H ldap://fqdn.of.host option.
>>
>> _______________________________________________
>> Freeipa-users mailing list
>> Freeipa-***@redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>
Macklin, Jason
2012-10-17 18:49:36 UTC
Permalink
ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W -b "dc=dbr,dc=roche,dc=com" uid=asteinfeld \*
Enter LDAP Password:
dn: uid=asteinfeld,cn=users,cn=compat,dc=dbr,dc=roche,dc=com
objectClass: posixAccount
objectClass: top
gecos: Axel Steinfeld
cn: Axel Steinfeld
uidNumber: 2011
gidNumber: 2011
loginShell: /bin/bash
homeDirectory: /home2/asteinfeld
uid: asteinfeld

dn: uid=asteinfeld,cn=users,cn=accounts,dc=dbr,dc=roche,dc=com
displayName: Axel Steinfeld
cn: Axel Steinfeld
objectClass: top
objectClass: person
objectClass: organizationalperson
objectClass: inetorgperson
objectClass: inetuser
objectClass: posixaccount
objectClass: krbprincipalaux
objectClass: krbticketpolicyaux
objectClass: ipaobject
objectClass: mepOriginEntry
loginShell: /bin/bash
sn: Steinfeld
uidNumber: 2011
gidNumber: 2011
gecos: Axel Steinfeld
homeDirectory: /home2/asteinfeld
krbPwdPolicyReference: cn=global_policy,cn=DBR.ROCHE.COM,cn=kerberos,dc=dbr,dc
=roche,dc=com
krbPrincipalName: ***@DBR.ROCHE.COM
givenName: Axel
uid: asteinfeld
initials: AS
userPassword:: e1NTSEF9OGpRZ09pazNWbGV0QlRTdm9DSjQ5b0VwaDhIQzZ5aHJ6Z2Foanc9PQ=
=
ipaUniqueID: e582ea10-9e89-11e1-a7db-005056bb0010
krbPrincipalKey:: MIIC7qADAgEBoQMCAQGiAwIBA6MDAgEBpIIC1jCCAtIwb6AiMCCgAwIBAKEZ
BBdEQlIuUk9DSEUuQ09NYXN0ZWluZmVsZKFJMEegAwIBEqFABD4gAKO2YZ6bzFkcvDQUQR1R0AEFO
o+oNDP7NlR75fVLZ0932O8fxrDnbKL90Ti3N6AQJpaZzvUrDozy70LSbjBfoCIwIKADAgEAoRkEF0
RCUi5ST0NIRS5DT01hc3RlaW5mZWxkoTkwN6ADAgERoTAELhAAIROPMbj/O/5yV9gynI1rc2CtckV
mu7PczKYvb0O/Wk8D8QwBQyFSryrwMQAwZ6AiMCCgAwIBAKEZBBdEQlIuUk9DSEUuQ09NYXN0ZWlu
ZmVsZKFBMD+gAwIBEKE4BDYYANU+Z6tmBZfUx5d7gf6NazwtXIlJsxZQZ8ntFigMGQxTjk4W/hDiz
ECD0a6hskJuhmi8OjAwX6AiMCCgAwIBAKEZBBdEQlIuUk9DSEUuQ09NYXN0ZWluZmVsZKE5MDegAw
IBF6EwBC4QADS3VnBvucc3YHvX0sL9YiASCYV7Iq5UV2seIw4bYlWt0b5RpLR5/fpbPyA5MFegIjA
goAMCAQChGQQXREJSLlJPQ0hFLkNPTWFzdGVpbmZlbGShMTAvoAMCAQihKAQmCADwSRXiuHorXYmh
UNvxq+HX/4j/dVSqr5vJ02anMGlZZnduCZcwV6AiMCCgAwIBAKEZBBdEQlIuUk9DSEUuQ09NYXN0Z
WluZmVsZKExMC+gAwIBA6EoBCYIANEhS6vyfY9cpethqr64UZcf4XWMQFPYmvkrU6+qlWCnCqfKiD
AzoTEwL6ADAgEBoSgEJggA6TGpzIElqIiEN+bgeZYSUJm5G/o3nORRyg1oAp8C1H35cyyVME2gGDA
WoAMCAQWhDwQNREJSLlJPQ0hFLkNPTaExMC+gAwIBAaEoBCYIACSVJDR+FFTCMrmWMcwwT4F47jxL
LaAac0/gncsxU5+VR+jgfg==
krbPasswordExpiration: 20130324201805Z
krbLastPwdChange: 20120925201805Z
krbExtraData:: AAJ9EWJQa2FkbWluZEBEQlIuUk9DSEUuQ09NAA==
mepManagedEntry: cn=asteinfeld,cn=groups,cn=accounts,dc=dbr,dc=roche,dc=com
memberOf: cn=dbr,cn=groups,cn=accounts,dc=dbr,dc=roche,dc=com
memberOf: ipaUniqueID=be53ab18-0820-11e2-9b0a-005056bb0010,cn=sudorules,cn=sud
o,dc=dbr,dc=roche,dc=com
memberOf: cn=tempsudo,cn=groups,cn=accounts,dc=dbr,dc=roche,dc=com
memberOf: ipaUniqueID=00544f1a-17a6-11e2-8dde-005056bb0010,cn=sudorules,cn=sud
o,dc=dbr,dc=roche,dc=com
memberOf: ipaUniqueID=9a7ec120-185e-11e2-891c-005056bb0010,cn=hbac,dc=dbr,dc=r
oche,dc=com
krbLoginFailedCount: 0
krbLastSuccessfulAuth: 20121017184614Z
krbTicketFlags: 128
krbLastFailedAuth: 20121015143818Z

[***@dbduwdu062 Desktop]$ ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W -b "dc=dbr,dc=roche,dc=com" uid=jmacklin \*Enter LDAP Password:
dn: uid=jmacklin,cn=users,cn=compat,dc=dbr,dc=roche,dc=com
objectClass: posixAccount
objectClass: top
gecos: Jason Macklin
cn: Jason Macklin
uidNumber: 2084
gidNumber: 2084
loginShell: /bin/bash
homeDirectory: /home2/jmacklin
uid: jmacklin

dn: uid=jmacklin,cn=users,cn=accounts,dc=dbr,dc=roche,dc=com
displayName: Jason Macklin
cn: Jason Macklin
objectClass: top
objectClass: person
objectClass: organizationalperson
objectClass: inetorgperson
objectClass: inetuser
objectClass: posixaccount
objectClass: krbprincipalaux
objectClass: krbticketpolicyaux
objectClass: ipaobject
objectClass: mepOriginEntry
loginShell: /bin/bash
sn: Macklin
gecos: Jason Macklin
homeDirectory: /home2/jmacklin
krbPwdPolicyReference: cn=global_policy,cn=DBR.ROCHE.COM,cn=kerberos,dc=dbr,dc
=roche,dc=com
krbPrincipalName: ***@DBR.ROCHE.COM
givenName: Jason
uid: jmacklin
initials: JM
uidNumber: 2084
gidNumber: 2084
ipaUniqueID: 045652b4-8e3c-11e1-831f-005056bb0010
mepManagedEntry: cn=jmacklin,cn=groups,cn=accounts,dc=dbr,dc=roche,dc=com
memberOf: cn=admins,cn=groups,cn=accounts,dc=dbr,dc=roche,dc=com
memberOf: cn=Replication Administrators,cn=privileges,cn=pbac,dc=dbr,dc=roche,
dc=com
memberOf: cn=Add Replication Agreements,cn=permissions,cn=pbac,dc=dbr,dc=roche
,dc=com
memberOf: cn=Modify Replication Agreements,cn=permissions,cn=pbac,dc=dbr,dc=ro
che,dc=com
memberOf: cn=Remove Replication Agreements,cn=permissions,cn=pbac,dc=dbr,dc=ro
che,dc=com
memberOf: cn=Host Enrollment,cn=privileges,cn=pbac,dc=dbr,dc=roche,dc=com
memberOf: cn=Manage host keytab,cn=permissions,cn=pbac,dc=dbr,dc=roche,dc=com
memberOf: cn=Enroll a host,cn=permissions,cn=pbac,dc=dbr,dc=roche,dc=com
memberOf: cn=Add krbPrincipalName to a host,cn=permissions,cn=pbac,dc=dbr,dc=r
oche,dc=com
memberOf: cn=Unlock user accounts,cn=permissions,cn=pbac,dc=dbr,dc=roche,dc=co
m
memberOf: cn=Manage service keytab,cn=permissions,cn=pbac,dc=dbr,dc=roche,dc=c
om
memberOf: cn=dbr,cn=groups,cn=accounts,dc=dbr,dc=roche,dc=com
memberOf: ipaUniqueID=23216c12-9934-11e1-bd4c-005056bb0010,cn=sudorules,cn=sud
o,dc=dbr,dc=roche,dc=com
krbLastFailedAuth: 20121017164159Z
krbPrincipalKey:: MIIC4qADAgEBoQMCAQGiAwIBBaMDAgEBpIICyjCCAsYwbaAgMB6gAwIBAKEX
BBVEQlIuUk9DSEUuQ09Nam1hY2tsaW6hSTBHoAMCARKhQAQ+IACOG0H0Ebd8nSSY6zU3Y29ZHtQ9a
sC2QJFL/lnbaFO1DYG15WjJYXnJ7k3m0LN0aTyjvz7FN4OWMF4tvvowXaAgMB6gAwIBAKEXBBVEQl
IuUk9DSEUuQ09Nam1hY2tsaW6hOTA3oAMCARGhMAQuEAD6UdNSe/mp8qqi4OuT7HOqIs80DFQDRny
37aZaD4lYrFsnQiBtpnpMnNSxADBloCAwHqADAgEAoRcEFURCUi5ST0NIRS5DT01qbWFja2xpbqFB
MD+gAwIBEKE4BDYYADAQZLDW61U+4aEZT4b+/X/OpiQLHTQlyIUolm9EjVG4wXu+8Mn4lMYMZyR/F
Gw6NWeeq1kwXaAgMB6gAwIBAKEXBBVEQlIuUk9DSEUuQ09Nam1hY2tsaW6hOTA3oAMCARehMAQuEA
CiWDGd28XkiaDAwpGyK0MqSawLCXs+jKOFAA5BoSpayVTJJqjzAwSEitSu5zBVoCAwHqADAgEAoRc
EFURCUi5ST0NIRS5DT01qbWFja2xpbqExMC+gAwIBCKEoBCYIAKL5bzV4nQide/+6/2FE5LxYGULv
8Ws/Uu0RXrwAnR8/ZuUh0TBVoCAwHqADAgEAoRcEFURCUi5ST0NIRS5DT01qbWFja2xpbqExMC+gA
wIBA6EoBCYIANgV0agxRmfBwY2Cb7gPlm1oWDY5qhZidd8a0KmeIlBG56XLZjAzoTEwL6ADAgEBoS
gEJggAo/BQC7g4SWQY0UkU7rvoOAXwobVlAZn8mesgQEznRDr2+bxjME2gGDAWoAMCAQWhDwQNREJ
SLlJPQ0hFLkNPTaExMC+gAwIBAaEoBCYIAMDDcwjYU6jLJTnE+Lzs0Ulxgf4FDEnTRXTjfJBqXIJb
R5aBPg==
krbLastPwdChange: 20120809140419Z
krbPasswordExpiration: 20130205140419Z
userPassword:: e1NTSEF9a0NXcUxTc1JOQ2tEUVlLVVF4VTdJLzh1TXREVnBWZjlnMWRxa0E9PQ=
=
krbExtraData:: AAJjwyNQa2FkbWluZEBEQlIuUk9DSEUuQ09NAA==
krbLastSuccessfulAuth: 20121017184444Z
krbLoginFailedCount: 0
krbTicketFlags: 128

So with all of that output, I would like to mention the discrepancy with ldap.conf. Just trying to get any "sudo" working on RHEL 6.3 was problematic until I stumbled upon a post that mentioned creating/editing /etc/sudo-ldap.conf rather then /etc/ldap.conf or /etc/openldap/ldap.conf. If I remove the /etc/sudo-ldap.conf then I have no sudo capabilities at all.

-----Original Message-----
From: Rich Megginson [mailto:***@redhat.com]
Sent: Wednesday, October 17, 2012 2:06 PM
To: Macklin, Jason {DASB~Branford}
Cc: ***@redhat.com; freeipa-***@redhat.com
Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.

On 10/17/2012 11:51 AM, Macklin, Jason wrote:
> I assume that this iteration was with the correct credentials as it responds with something other then "Invalid Credentials"
>
> ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W uid=asteinfeld \* krbPwdLockoutDuration ?
> Enter LDAP Password:
> No such object (32)
>
> Working account returns same thing...
>
> ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W uid=jmacklin \* krbPwdLockoutDuration ?
> Enter LDAP Password:
> No such object (32)

Sorry, I though ipa would have configured your /etc/openldap/ldap.conf with your base dn. Try this:

ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W -b "dc=dbr,dc=roche,dc=com" uid=jmacklin \*
>
> -----Original Message-----
> From: Rob Crittenden [mailto:***@redhat.com]
> Sent: Wednesday, October 17, 2012 1:37 PM
> To: Macklin, Jason {DASB~Branford}
> Cc: ***@redhat.com; freeipa-***@redhat.com
> Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
>
> Macklin, Jason wrote:
>> ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W uid=asteinfeld \* krbPwdLockoutDuration ?
>> Enter LDAP Password:
>> ldap_bind: Invalid credentials (49)
>>
>> I know this user password because I reset it for the purpose of troubleshooting this issue with that account. I also get the same response when I use the admin account of my own account.
> You use the password of the user you are binding as, in this case the directory manager.
>
> rob
>
>> -----Original Message-----
>> From: Rich Megginson [mailto:***@redhat.com]
>> Sent: Wednesday, October 17, 2012 1:15 PM
>> To: Macklin, Jason {DASB~Branford}
>> Cc: ***@redhat.com; freeipa-***@redhat.com
>> Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
>>
>> On 10/17/2012 11:13 AM, Macklin, Jason wrote:
>>> None of my users have an LDAP password being requested by running that command (except the admin user).
>>>
>>> Does each user account require an ldap account to go along with their login account? I just get the following over and over no matter which account I switch in the command...
>>>
>>> [***@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=admin \* krbPwdLockoutDuration ?
>>> Enter LDAP Password:
>>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
>>> [***@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=asteinfeld \* krbPwdLockoutDuration ?
>>> Enter LDAP Password:
>>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
>>> [***@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=jmacklin \* krbPwdLockoutDuration ?
>>> Enter LDAP Password:
>>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
>> You have to specify which server to talk to using the -H ldap://fqdn.of.host option.
>>
>> _______________________________________________
>> Freeipa-users mailing list
>> Freeipa-***@redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>
Rich Megginson
2012-10-17 19:18:22 UTC
Permalink
On 10/17/2012 12:49 PM, Macklin, Jason wrote:
> ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W -b "dc=dbr,dc=roche,dc=com" uid=asteinfeld \*
<snip>
>
> dn: uid=asteinfeld,cn=users,cn=accounts,dc=dbr,dc=roche,dc=com
...snip...
> krbPrincipalName: ***@DBR.ROCHE.COM
> krbPasswordExpiration: 20130324201805Z
> krbLastPwdChange: 20120925201805Z
> krbLoginFailedCount: 0
> krbLastSuccessfulAuth: 20121017184614Z
> krbTicketFlags: 128
> krbLastFailedAuth: 20121015143818Z

No krbPwdLockoutDuration attribute - so according to ipalockout_preop()
this means the "Entry permanently locked". Not sure why.
>
> [***@dbduwdu062 Desktop]$ ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W -b "dc=dbr,dc=roche,dc=com" uid=jmacklin \*Enter LDAP Password:
> dn: uid=jmacklin,cn=users,cn=compat,dc=dbr,dc=roche,dc=com
> objectClass: posixAccount
> objectClass: top
> gecos: Jason Macklin
> cn: Jason Macklin
> uidNumber: 2084
> gidNumber: 2084
> loginShell: /bin/bash
> homeDirectory: /home2/jmacklin
> uid: jmacklin
>
> dn: uid=jmacklin,cn=users,cn=accounts,dc=dbr,dc=roche,dc=com
> displayName: Jason Macklin
> cn: Jason Macklin
> objectClass: top
> objectClass: person
> objectClass: organizationalperson
> objectClass: inetorgperson
> objectClass: inetuser
> objectClass: posixaccount
> objectClass: krbprincipalaux
> objectClass: krbticketpolicyaux
> objectClass: ipaobject
> objectClass: mepOriginEntry
> loginShell: /bin/bash
> sn: Macklin
> gecos: Jason Macklin
> homeDirectory: /home2/jmacklin
> krbPwdPolicyReference: cn=global_policy,cn=DBR.ROCHE.COM,cn=kerberos,dc=dbr,dc
> =roche,dc=com
> krbPrincipalName: ***@DBR.ROCHE.COM
> givenName: Jason
> uid: jmacklin
> initials: JM
> uidNumber: 2084
> gidNumber: 2084
> ipaUniqueID: 045652b4-8e3c-11e1-831f-005056bb0010
> mepManagedEntry: cn=jmacklin,cn=groups,cn=accounts,dc=dbr,dc=roche,dc=com
> memberOf: cn=admins,cn=groups,cn=accounts,dc=dbr,dc=roche,dc=com
> memberOf: cn=Replication Administrators,cn=privileges,cn=pbac,dc=dbr,dc=roche,
> dc=com
> memberOf: cn=Add Replication Agreements,cn=permissions,cn=pbac,dc=dbr,dc=roche
> ,dc=com
> memberOf: cn=Modify Replication Agreements,cn=permissions,cn=pbac,dc=dbr,dc=ro
> che,dc=com
> memberOf: cn=Remove Replication Agreements,cn=permissions,cn=pbac,dc=dbr,dc=ro
> che,dc=com
> memberOf: cn=Host Enrollment,cn=privileges,cn=pbac,dc=dbr,dc=roche,dc=com
> memberOf: cn=Manage host keytab,cn=permissions,cn=pbac,dc=dbr,dc=roche,dc=com
> memberOf: cn=Enroll a host,cn=permissions,cn=pbac,dc=dbr,dc=roche,dc=com
> memberOf: cn=Add krbPrincipalName to a host,cn=permissions,cn=pbac,dc=dbr,dc=r
> oche,dc=com
> memberOf: cn=Unlock user accounts,cn=permissions,cn=pbac,dc=dbr,dc=roche,dc=co
> m
> memberOf: cn=Manage service keytab,cn=permissions,cn=pbac,dc=dbr,dc=roche,dc=c
> om
> memberOf: cn=dbr,cn=groups,cn=accounts,dc=dbr,dc=roche,dc=com
> memberOf: ipaUniqueID=23216c12-9934-11e1-bd4c-005056bb0010,cn=sudorules,cn=sud
> o,dc=dbr,dc=roche,dc=com
> krbLastFailedAuth: 20121017164159Z
> krbPrincipalKey:: MIIC4qADAgEBoQMCAQGiAwIBBaMDAgEBpIICyjCCAsYwbaAgMB6gAwIBAKEX
> BBVEQlIuUk9DSEUuQ09Nam1hY2tsaW6hSTBHoAMCARKhQAQ+IACOG0H0Ebd8nSSY6zU3Y29ZHtQ9a
> sC2QJFL/lnbaFO1DYG15WjJYXnJ7k3m0LN0aTyjvz7FN4OWMF4tvvowXaAgMB6gAwIBAKEXBBVEQl
> IuUk9DSEUuQ09Nam1hY2tsaW6hOTA3oAMCARGhMAQuEAD6UdNSe/mp8qqi4OuT7HOqIs80DFQDRny
> 37aZaD4lYrFsnQiBtpnpMnNSxADBloCAwHqADAgEAoRcEFURCUi5ST0NIRS5DT01qbWFja2xpbqFB
> MD+gAwIBEKE4BDYYADAQZLDW61U+4aEZT4b+/X/OpiQLHTQlyIUolm9EjVG4wXu+8Mn4lMYMZyR/F
> Gw6NWeeq1kwXaAgMB6gAwIBAKEXBBVEQlIuUk9DSEUuQ09Nam1hY2tsaW6hOTA3oAMCARehMAQuEA
> CiWDGd28XkiaDAwpGyK0MqSawLCXs+jKOFAA5BoSpayVTJJqjzAwSEitSu5zBVoCAwHqADAgEAoRc
> EFURCUi5ST0NIRS5DT01qbWFja2xpbqExMC+gAwIBCKEoBCYIAKL5bzV4nQide/+6/2FE5LxYGULv
> 8Ws/Uu0RXrwAnR8/ZuUh0TBVoCAwHqADAgEAoRcEFURCUi5ST0NIRS5DT01qbWFja2xpbqExMC+gA
> wIBA6EoBCYIANgV0agxRmfBwY2Cb7gPlm1oWDY5qhZidd8a0KmeIlBG56XLZjAzoTEwL6ADAgEBoS
> gEJggAo/BQC7g4SWQY0UkU7rvoOAXwobVlAZn8mesgQEznRDr2+bxjME2gGDAWoAMCAQWhDwQNREJ
> SLlJPQ0hFLkNPTaExMC+gAwIBAaEoBCYIAMDDcwjYU6jLJTnE+Lzs0Ulxgf4FDEnTRXTjfJBqXIJb
> R5aBPg==
> krbLastPwdChange: 20120809140419Z
> krbPasswordExpiration: 20130205140419Z
> userPassword:: e1NTSEF9a0NXcUxTc1JOQ2tEUVlLVVF4VTdJLzh1TXREVnBWZjlnMWRxa0E9PQ=
> =
> krbExtraData:: AAJjwyNQa2FkbWluZEBEQlIuUk9DSEUuQ09NAA==
> krbLastSuccessfulAuth: 20121017184444Z
> krbLoginFailedCount: 0
> krbTicketFlags: 128
>
> So with all of that output, I would like to mention the discrepancy with ldap.conf. Just trying to get any "sudo" working on RHEL 6.3 was problematic until I stumbled upon a post that mentioned creating/editing /etc/sudo-ldap.conf rather then /etc/ldap.conf or /etc/openldap/ldap.conf. If I remove the /etc/sudo-ldap.conf then I have no sudo capabilities at all.
>
> -----Original Message-----
> From: Rich Megginson [mailto:***@redhat.com]
> Sent: Wednesday, October 17, 2012 2:06 PM
> To: Macklin, Jason {DASB~Branford}
> Cc: ***@redhat.com; freeipa-***@redhat.com
> Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
>
> On 10/17/2012 11:51 AM, Macklin, Jason wrote:
>> I assume that this iteration was with the correct credentials as it responds with something other then "Invalid Credentials"
>>
>> ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W uid=asteinfeld \* krbPwdLockoutDuration ?
>> Enter LDAP Password:
>> No such object (32)
>>
>> Working account returns same thing...
>>
>> ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W uid=jmacklin \* krbPwdLockoutDuration ?
>> Enter LDAP Password:
>> No such object (32)
> Sorry, I though ipa would have configured your /etc/openldap/ldap.conf with your base dn. Try this:
>
> ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W -b "dc=dbr,dc=roche,dc=com" uid=jmacklin \*
>> -----Original Message-----
>> From: Rob Crittenden [mailto:***@redhat.com]
>> Sent: Wednesday, October 17, 2012 1:37 PM
>> To: Macklin, Jason {DASB~Branford}
>> Cc: ***@redhat.com; freeipa-***@redhat.com
>> Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
>>
>> Macklin, Jason wrote:
>>> ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W uid=asteinfeld \* krbPwdLockoutDuration ?
>>> Enter LDAP Password:
>>> ldap_bind: Invalid credentials (49)
>>>
>>> I know this user password because I reset it for the purpose of troubleshooting this issue with that account. I also get the same response when I use the admin account of my own account.
>> You use the password of the user you are binding as, in this case the directory manager.
>>
>> rob
>>
>>> -----Original Message-----
>>> From: Rich Megginson [mailto:***@redhat.com]
>>> Sent: Wednesday, October 17, 2012 1:15 PM
>>> To: Macklin, Jason {DASB~Branford}
>>> Cc: ***@redhat.com; freeipa-***@redhat.com
>>> Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
>>>
>>> On 10/17/2012 11:13 AM, Macklin, Jason wrote:
>>>> None of my users have an LDAP password being requested by running that command (except the admin user).
>>>>
>>>> Does each user account require an ldap account to go along with their login account? I just get the following over and over no matter which account I switch in the command...
>>>>
>>>> [***@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=admin \* krbPwdLockoutDuration ?
>>>> Enter LDAP Password:
>>>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
>>>> [***@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=asteinfeld \* krbPwdLockoutDuration ?
>>>> Enter LDAP Password:
>>>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
>>>> [***@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=jmacklin \* krbPwdLockoutDuration ?
>>>> Enter LDAP Password:
>>>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
>>> You have to specify which server to talk to using the -H ldap://fqdn.of.host option.
>>>
>>> _______________________________________________
>>> Freeipa-users mailing list
>>> Freeipa-***@redhat.com
>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>>
Rob Crittenden
2012-10-17 19:26:41 UTC
Permalink
Rich Megginson wrote:
> On 10/17/2012 12:49 PM, Macklin, Jason wrote:
>> ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory
>> manager" -W -b "dc=dbr,dc=roche,dc=com" uid=asteinfeld \*
> <snip>
>>
>> dn: uid=asteinfeld,cn=users,cn=accounts,dc=dbr,dc=roche,dc=com
> ...snip...
>> krbPrincipalName: ***@DBR.ROCHE.COM
>> krbPasswordExpiration: 20130324201805Z
>> krbLastPwdChange: 20120925201805Z
>> krbLoginFailedCount: 0
>> krbLastSuccessfulAuth: 20121017184614Z
>> krbTicketFlags: 128
>> krbLastFailedAuth: 20121015143818Z
>
> No krbPwdLockoutDuration attribute - so according to ipalockout_preop()
> this means the "Entry permanently locked". Not sure why.

I don't believe this applies if the attribute doesn't exist. It doesn't
for any of my test users and it works fine.

>>
>> [***@dbduwdu062 Desktop]$ ldapsearch -xLLL -H
>> ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W -b
>> "dc=dbr,dc=roche,dc=com" uid=jmacklin \*Enter LDAP Password:
>> dn: uid=jmacklin,cn=users,cn=compat,dc=dbr,dc=roche,dc=com
>> objectClass: posixAccount
>> objectClass: top
>> gecos: Jason Macklin
>> cn: Jason Macklin
>> uidNumber: 2084
>> gidNumber: 2084
>> loginShell: /bin/bash
>> homeDirectory: /home2/jmacklin
>> uid: jmacklin
>>
>> dn: uid=jmacklin,cn=users,cn=accounts,dc=dbr,dc=roche,dc=com
>> displayName: Jason Macklin
>> cn: Jason Macklin
>> objectClass: top
>> objectClass: person
>> objectClass: organizationalperson
>> objectClass: inetorgperson
>> objectClass: inetuser
>> objectClass: posixaccount
>> objectClass: krbprincipalaux
>> objectClass: krbticketpolicyaux
>> objectClass: ipaobject
>> objectClass: mepOriginEntry
>> loginShell: /bin/bash
>> sn: Macklin
>> gecos: Jason Macklin
>> homeDirectory: /home2/jmacklin
>> krbPwdPolicyReference:
>> cn=global_policy,cn=DBR.ROCHE.COM,cn=kerberos,dc=dbr,dc
>> =roche,dc=com
>> krbPrincipalName: ***@DBR.ROCHE.COM
>> givenName: Jason
>> uid: jmacklin
>> initials: JM
>> uidNumber: 2084
>> gidNumber: 2084
>> ipaUniqueID: 045652b4-8e3c-11e1-831f-005056bb0010
>> mepManagedEntry: cn=jmacklin,cn=groups,cn=accounts,dc=dbr,dc=roche,dc=com
>> memberOf: cn=admins,cn=groups,cn=accounts,dc=dbr,dc=roche,dc=com
>> memberOf: cn=Replication
>> Administrators,cn=privileges,cn=pbac,dc=dbr,dc=roche,
>> dc=com
>> memberOf: cn=Add Replication
>> Agreements,cn=permissions,cn=pbac,dc=dbr,dc=roche
>> ,dc=com
>> memberOf: cn=Modify Replication
>> Agreements,cn=permissions,cn=pbac,dc=dbr,dc=ro
>> che,dc=com
>> memberOf: cn=Remove Replication
>> Agreements,cn=permissions,cn=pbac,dc=dbr,dc=ro
>> che,dc=com
>> memberOf: cn=Host Enrollment,cn=privileges,cn=pbac,dc=dbr,dc=roche,dc=com
>> memberOf: cn=Manage host
>> keytab,cn=permissions,cn=pbac,dc=dbr,dc=roche,dc=com
>> memberOf: cn=Enroll a host,cn=permissions,cn=pbac,dc=dbr,dc=roche,dc=com
>> memberOf: cn=Add krbPrincipalName to a
>> host,cn=permissions,cn=pbac,dc=dbr,dc=r
>> oche,dc=com
>> memberOf: cn=Unlock user
>> accounts,cn=permissions,cn=pbac,dc=dbr,dc=roche,dc=co
>> m
>> memberOf: cn=Manage service
>> keytab,cn=permissions,cn=pbac,dc=dbr,dc=roche,dc=c
>> om
>> memberOf: cn=dbr,cn=groups,cn=accounts,dc=dbr,dc=roche,dc=com
>> memberOf:
>> ipaUniqueID=23216c12-9934-11e1-bd4c-005056bb0010,cn=sudorules,cn=sud
>> o,dc=dbr,dc=roche,dc=com
>> krbLastFailedAuth: 20121017164159Z
>> krbPrincipalKey::
>> MIIC4qADAgEBoQMCAQGiAwIBBaMDAgEBpIICyjCCAsYwbaAgMB6gAwIBAKEX
>>
>> BBVEQlIuUk9DSEUuQ09Nam1hY2tsaW6hSTBHoAMCARKhQAQ+IACOG0H0Ebd8nSSY6zU3Y29ZHtQ9a
>>
>>
>> sC2QJFL/lnbaFO1DYG15WjJYXnJ7k3m0LN0aTyjvz7FN4OWMF4tvvowXaAgMB6gAwIBAKEXBBVEQl
>>
>>
>> IuUk9DSEUuQ09Nam1hY2tsaW6hOTA3oAMCARGhMAQuEAD6UdNSe/mp8qqi4OuT7HOqIs80DFQDRny
>>
>>
>> 37aZaD4lYrFsnQiBtpnpMnNSxADBloCAwHqADAgEAoRcEFURCUi5ST0NIRS5DT01qbWFja2xpbqFB
>>
>>
>> MD+gAwIBEKE4BDYYADAQZLDW61U+4aEZT4b+/X/OpiQLHTQlyIUolm9EjVG4wXu+8Mn4lMYMZyR/F
>>
>>
>> Gw6NWeeq1kwXaAgMB6gAwIBAKEXBBVEQlIuUk9DSEUuQ09Nam1hY2tsaW6hOTA3oAMCARehMAQuEA
>>
>>
>> CiWDGd28XkiaDAwpGyK0MqSawLCXs+jKOFAA5BoSpayVTJJqjzAwSEitSu5zBVoCAwHqADAgEAoRc
>>
>>
>> EFURCUi5ST0NIRS5DT01qbWFja2xpbqExMC+gAwIBCKEoBCYIAKL5bzV4nQide/+6/2FE5LxYGULv
>>
>>
>> 8Ws/Uu0RXrwAnR8/ZuUh0TBVoCAwHqADAgEAoRcEFURCUi5ST0NIRS5DT01qbWFja2xpbqExMC+gA
>>
>>
>> wIBA6EoBCYIANgV0agxRmfBwY2Cb7gPlm1oWDY5qhZidd8a0KmeIlBG56XLZjAzoTEwL6ADAgEBoS
>>
>>
>> gEJggAo/BQC7g4SWQY0UkU7rvoOAXwobVlAZn8mesgQEznRDr2+bxjME2gGDAWoAMCAQWhDwQNREJ
>>
>>
>> SLlJPQ0hFLkNPTaExMC+gAwIBAaEoBCYIAMDDcwjYU6jLJTnE+Lzs0Ulxgf4FDEnTRXTjfJBqXIJb
>>
>> R5aBPg==
>> krbLastPwdChange: 20120809140419Z
>> krbPasswordExpiration: 20130205140419Z
>> userPassword::
>> e1NTSEF9a0NXcUxTc1JOQ2tEUVlLVVF4VTdJLzh1TXREVnBWZjlnMWRxa0E9PQ=
>> =
>> krbExtraData:: AAJjwyNQa2FkbWluZEBEQlIuUk9DSEUuQ09NAA==
>> krbLastSuccessfulAuth: 20121017184444Z
>> krbLoginFailedCount: 0
>> krbTicketFlags: 128
>>
>> So with all of that output, I would like to mention the discrepancy
>> with ldap.conf. Just trying to get any "sudo" working on RHEL 6.3 was
>> problematic until I stumbled upon a post that mentioned
>> creating/editing /etc/sudo-ldap.conf rather then /etc/ldap.conf or
>> /etc/openldap/ldap.conf. If I remove the /etc/sudo-ldap.conf then I
>> have no sudo capabilities at all.
>>
>> -----Original Message-----
>> From: Rich Megginson [mailto:***@redhat.com]
>> Sent: Wednesday, October 17, 2012 2:06 PM
>> To: Macklin, Jason {DASB~Branford}
>> Cc: ***@redhat.com; freeipa-***@redhat.com
>> Subject: Re: [Freeipa-users] Sudo works for full access, but not on a
>> per command or host level.
>>
>> On 10/17/2012 11:51 AM, Macklin, Jason wrote:
>>> I assume that this iteration was with the correct credentials as it
>>> responds with something other then "Invalid Credentials"
>>>
>>> ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory
>>> manager" -W uid=asteinfeld \* krbPwdLockoutDuration ?
>>> Enter LDAP Password:
>>> No such object (32)
>>>
>>> Working account returns same thing...
>>>
>>> ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory
>>> manager" -W uid=jmacklin \* krbPwdLockoutDuration ?
>>> Enter LDAP Password:
>>> No such object (32)
>> Sorry, I though ipa would have configured your /etc/openldap/ldap.conf
>> with your base dn. Try this:
>>
>> ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory
>> manager" -W -b "dc=dbr,dc=roche,dc=com" uid=jmacklin \*
>>> -----Original Message-----
>>> From: Rob Crittenden [mailto:***@redhat.com]
>>> Sent: Wednesday, October 17, 2012 1:37 PM
>>> To: Macklin, Jason {DASB~Branford}
>>> Cc: ***@redhat.com; freeipa-***@redhat.com
>>> Subject: Re: [Freeipa-users] Sudo works for full access, but not on a
>>> per command or host level.
>>>
>>> Macklin, Jason wrote:
>>>> ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory
>>>> manager" -W uid=asteinfeld \* krbPwdLockoutDuration ?
>>>> Enter LDAP Password:
>>>> ldap_bind: Invalid credentials (49)
>>>>
>>>> I know this user password because I reset it for the purpose of
>>>> troubleshooting this issue with that account. I also get the same
>>>> response when I use the admin account of my own account.
>>> You use the password of the user you are binding as, in this case the
>>> directory manager.
>>>
>>> rob
>>>
>>>> -----Original Message-----
>>>> From: Rich Megginson [mailto:***@redhat.com]
>>>> Sent: Wednesday, October 17, 2012 1:15 PM
>>>> To: Macklin, Jason {DASB~Branford}
>>>> Cc: ***@redhat.com; freeipa-***@redhat.com
>>>> Subject: Re: [Freeipa-users] Sudo works for full access, but not on
>>>> a per command or host level.
>>>>
>>>> On 10/17/2012 11:13 AM, Macklin, Jason wrote:
>>>>> None of my users have an LDAP password being requested by running
>>>>> that command (except the admin user).
>>>>>
>>>>> Does each user account require an ldap account to go along with
>>>>> their login account? I just get the following over and over no
>>>>> matter which account I switch in the command...
>>>>>
>>>>> [***@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory
>>>>> manager" -W uid=admin \* krbPwdLockoutDuration ?
>>>>> Enter LDAP Password:
>>>>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
>>>>> [***@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory
>>>>> manager" -W uid=asteinfeld \* krbPwdLockoutDuration ?
>>>>> Enter LDAP Password:
>>>>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
>>>>> [***@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory
>>>>> manager" -W uid=jmacklin \* krbPwdLockoutDuration ?
>>>>> Enter LDAP Password:
>>>>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
>>>> You have to specify which server to talk to using the -H
>>>> ldap://fqdn.of.host option.
>>>>
>>>> _______________________________________________
>>>> Freeipa-users mailing list
>>>> Freeipa-***@redhat.com
>>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>>>
>
Toasted Penguin
2012-10-17 19:53:27 UTC
Permalink
On Wed, Oct 17, 2012 at 2:26 PM, Rob Crittenden <***@redhat.com> wrote:

> Rich Megginson wrote:
>
>> On 10/17/2012 12:49 PM, Macklin, Jason wrote:
>>
>>> ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.**com<http://dbduvdu145.dbr.roche.com>-D "cn=directory
>>> manager" -W -b "dc=dbr,dc=roche,dc=com" uid=asteinfeld \*
>>>
>> <snip>
>>
>>>
>>> dn: uid=asteinfeld,cn=users,cn=**accounts,dc=dbr,dc=roche,dc=**com
>>>
>> ...snip...
>>
>>> krbPrincipalName: ***@DBR.ROCHE.COM
>>> krbPasswordExpiration: 20130324201805Z
>>> krbLastPwdChange: 20120925201805Z
>>> krbLoginFailedCount: 0
>>> krbLastSuccessfulAuth: 20121017184614Z
>>> krbTicketFlags: 128
>>> krbLastFailedAuth: 20121015143818Z
>>>
>>
>> No krbPwdLockoutDuration attribute - so according to ipalockout_preop()
>> this means the "Entry permanently locked". Not sure why.
>>
>
> I don't believe this applies if the attribute doesn't exist. It doesn't
> for any of my test users and it works fine.
>
>
>
>>> [***@dbduwdu062 Desktop]$ ldapsearch -xLLL -H
>>> ldap://dbduvdu145.dbr.roche.**com <http://dbduvdu145.dbr.roche.com> -D
>>> "cn=directory manager" -W -b
>>> "dc=dbr,dc=roche,dc=com" uid=jmacklin \*Enter LDAP Password:
>>> dn: uid=jmacklin,cn=users,cn=**compat,dc=dbr,dc=roche,dc=com
>>> objectClass: posixAccount
>>> objectClass: top
>>> gecos: Jason Macklin
>>> cn: Jason Macklin
>>> uidNumber: 2084
>>> gidNumber: 2084
>>> loginShell: /bin/bash
>>> homeDirectory: /home2/jmacklin
>>> uid: jmacklin
>>>
>>> dn: uid=jmacklin,cn=users,cn=**accounts,dc=dbr,dc=roche,dc=**com
>>> displayName: Jason Macklin
>>> cn: Jason Macklin
>>> objectClass: top
>>> objectClass: person
>>> objectClass: organizationalperson
>>> objectClass: inetorgperson
>>> objectClass: inetuser
>>> objectClass: posixaccount
>>> objectClass: krbprincipalaux
>>> objectClass: krbticketpolicyaux
>>> objectClass: ipaobject
>>> objectClass: mepOriginEntry
>>> loginShell: /bin/bash
>>> sn: Macklin
>>> gecos: Jason Macklin
>>> homeDirectory: /home2/jmacklin
>>> krbPwdPolicyReference:
>>> cn=global_policy,cn=DBR.ROCHE.**COM <http://DBR.ROCHE.COM>
>>> ,cn=kerberos,dc=dbr,dc
>>> =roche,dc=com
>>> krbPrincipalName: ***@DBR.ROCHE.COM
>>> givenName: Jason
>>> uid: jmacklin
>>> initials: JM
>>> uidNumber: 2084
>>> gidNumber: 2084
>>> ipaUniqueID: 045652b4-8e3c-11e1-831f-**005056bb0010
>>> mepManagedEntry: cn=jmacklin,cn=groups,cn=**accounts,dc=dbr,dc=roche,dc=
>>> **com
>>> memberOf: cn=admins,cn=groups,cn=**accounts,dc=dbr,dc=roche,dc=**com
>>> memberOf: cn=Replication
>>> Administrators,cn=privileges,**cn=pbac,dc=dbr,dc=roche,
>>> dc=com
>>> memberOf: cn=Add Replication
>>> Agreements,cn=permissions,cn=**pbac,dc=dbr,dc=roche
>>> ,dc=com
>>> memberOf: cn=Modify Replication
>>> Agreements,cn=permissions,cn=**pbac,dc=dbr,dc=ro
>>> che,dc=com
>>> memberOf: cn=Remove Replication
>>> Agreements,cn=permissions,cn=**pbac,dc=dbr,dc=ro
>>> che,dc=com
>>> memberOf: cn=Host Enrollment,cn=privileges,cn=**
>>> pbac,dc=dbr,dc=roche,dc=com
>>> memberOf: cn=Manage host
>>> keytab,cn=permissions,cn=pbac,**dc=dbr,dc=roche,dc=com
>>> memberOf: cn=Enroll a host,cn=permissions,cn=pbac,**
>>> dc=dbr,dc=roche,dc=com
>>> memberOf: cn=Add krbPrincipalName to a
>>> host,cn=permissions,cn=pbac,**dc=dbr,dc=r
>>> oche,dc=com
>>> memberOf: cn=Unlock user
>>> accounts,cn=permissions,cn=**pbac,dc=dbr,dc=roche,dc=co
>>> m
>>> memberOf: cn=Manage service
>>> keytab,cn=permissions,cn=pbac,**dc=dbr,dc=roche,dc=c
>>> om
>>> memberOf: cn=dbr,cn=groups,cn=accounts,**dc=dbr,dc=roche,dc=com
>>> memberOf:
>>> ipaUniqueID=23216c12-9934-**11e1-bd4c-005056bb0010,cn=**sudorules,cn=sud
>>> o,dc=dbr,dc=roche,dc=com
>>> krbLastFailedAuth: 20121017164159Z
>>> krbPrincipalKey::
>>> MIIC4qADAgEBoQMCAQGiAwIBBaMDAg**EBpIICyjCCAsYwbaAgMB6gAwIBAKEX
>>>
>>> BBVEQlIuUk9DSEUuQ09Nam1hY2tsaW**6hSTBHoAMCARKhQAQ+**
>>> IACOG0H0Ebd8nSSY6zU3Y29ZHtQ9a
>>>
>>>
>>> sC2QJFL/**lnbaFO1DYG15WjJYXnJ7k3m0LN0aTy**jvz7FN4OWMF4tvvowXaAgMB6gAwIBA
>>> **KEXBBVEQl
>>>
>>>
>>> IuUk9DSEUuQ09Nam1hY2tsaW6hOTA3**oAMCARGhMAQuEAD6UdNSe/**
>>> mp8qqi4OuT7HOqIs80DFQDRny
>>>
>>>
>>> 37aZaD4lYrFsnQiBtpnpMnNSxADBlo**CAwHqADAgEAoRcEFURCUi5ST0NIRS5**
>>> DT01qbWFja2xpbqFB
>>>
>>>
>>> MD+gAwIBEKE4BDYYADAQZLDW61U+**4aEZT4b+/X/**OpiQLHTQlyIUolm9EjVG4wXu+**
>>> 8Mn4lMYMZyR/F
>>>
>>>
>>> Gw6NWeeq1kwXaAgMB6gAwIBAKEXBBV**EQlIuUk9DSEUuQ09Nam1hY2tsaW6hO**
>>> TA3oAMCARehMAQuEA
>>>
>>>
>>> CiWDGd28XkiaDAwpGyK0MqSawLCXs+**jKOFAA5BoSpayVTJJqjzAwSEitSu5z**
>>> BVoCAwHqADAgEAoRc
>>>
>>>
>>> EFURCUi5ST0NIRS5DT01qbWFja2xpb**qExMC+**gAwIBCKEoBCYIAKL5bzV4nQide/+6/**
>>> 2FE5LxYGULv
>>>
>>>
>>> 8Ws/Uu0RXrwAnR8/**ZuUh0TBVoCAwHqADAgEAoRcEFURCUi**
>>> 5ST0NIRS5DT01qbWFja2xpbqExMC+**gA
>>>
>>>
>>> wIBA6EoBCYIANgV0agxRmfBwY2Cb7g**Plm1oWDY5qhZidd8a0KmeIlBG56XLZ**
>>> jAzoTEwL6ADAgEBoS
>>>
>>>
>>> gEJggAo/**BQC7g4SWQY0UkU7rvoOAXwobVlAZn8**mesgQEznRDr2+**
>>> bxjME2gGDAWoAMCAQWhDwQNREJ
>>>
>>>
>>> SLlJPQ0hFLkNPTaExMC+**gAwIBAaEoBCYIAMDDcwjYU6jLJTnE+**
>>> Lzs0Ulxgf4FDEnTRXTjfJBqXIJb
>>>
>>> R5aBPg==
>>> krbLastPwdChange: 20120809140419Z
>>> krbPasswordExpiration: 20130205140419Z
>>> userPassword::
>>> e1NTSEF9a0NXcUxTc1JOQ2tEUVlLVV**F4VTdJLzh1TXREVnBWZjlnMWRxa0E9**PQ=
>>> =
>>> krbExtraData:: AAJjwyNQa2FkbWluZEBEQlIuUk9DSE**UuQ09NAA==
>>> krbLastSuccessfulAuth: 20121017184444Z
>>> krbLoginFailedCount: 0
>>> krbTicketFlags: 128
>>>
>>> So with all of that output, I would like to mention the discrepancy
>>> with ldap.conf. Just trying to get any "sudo" working on RHEL 6.3 was
>>> problematic until I stumbled upon a post that mentioned
>>> creating/editing /etc/sudo-ldap.conf rather then /etc/ldap.conf or
>>> /etc/openldap/ldap.conf. If I remove the /etc/sudo-ldap.conf then I
>>> have no sudo capabilities at all.
>>>
>>> -----Original Message-----
>>> From: Rich Megginson [mailto:***@redhat.com]
>>> Sent: Wednesday, October 17, 2012 2:06 PM
>>> To: Macklin, Jason {DASB~Branford}
>>> Cc: ***@redhat.com; freeipa-***@redhat.com
>>> Subject: Re: [Freeipa-users] Sudo works for full access, but not on a
>>> per command or host level.
>>>
>>> On 10/17/2012 11:51 AM, Macklin, Jason wrote:
>>>
>>>> I assume that this iteration was with the correct credentials as it
>>>> responds with something other then "Invalid Credentials"
>>>>
>>>> ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.**com<http://dbduvdu145.dbr.roche.com>-D "cn=directory
>>>> manager" -W uid=asteinfeld \* krbPwdLockoutDuration ?
>>>> Enter LDAP Password:
>>>> No such object (32)
>>>>
>>>> Working account returns same thing...
>>>>
>>>> ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.**com<http://dbduvdu145.dbr.roche.com>-D "cn=directory
>>>> manager" -W uid=jmacklin \* krbPwdLockoutDuration ?
>>>> Enter LDAP Password:
>>>> No such object (32)
>>>>
>>> Sorry, I though ipa would have configured your /etc/openldap/ldap.conf
>>> with your base dn. Try this:
>>>
>>> ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.**com<http://dbduvdu145.dbr.roche.com>-D "cn=directory
>>> manager" -W -b "dc=dbr,dc=roche,dc=com" uid=jmacklin \*
>>>
>>>> -----Original Message-----
>>>> From: Rob Crittenden [mailto:***@redhat.com]
>>>> Sent: Wednesday, October 17, 2012 1:37 PM
>>>> To: Macklin, Jason {DASB~Branford}
>>>> Cc: ***@redhat.com; freeipa-***@redhat.com
>>>> Subject: Re: [Freeipa-users] Sudo works for full access, but not on a
>>>> per command or host level.
>>>>
>>>> Macklin, Jason wrote:
>>>>
>>>>> ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.**com<http://dbduvdu145.dbr.roche.com>-D "cn=directory
>>>>> manager" -W uid=asteinfeld \* krbPwdLockoutDuration ?
>>>>> Enter LDAP Password:
>>>>> ldap_bind: Invalid credentials (49)
>>>>>
>>>>> I know this user password because I reset it for the purpose of
>>>>> troubleshooting this issue with that account. I also get the same
>>>>> response when I use the admin account of my own account.
>>>>>
>>>> You use the password of the user you are binding as, in this case the
>>>> directory manager.
>>>>
>>>> rob
>>>>
>>>> -----Original Message-----
>>>>> From: Rich Megginson [mailto:***@redhat.com]
>>>>> Sent: Wednesday, October 17, 2012 1:15 PM
>>>>> To: Macklin, Jason {DASB~Branford}
>>>>> Cc: ***@redhat.com; freeipa-***@redhat.com
>>>>> Subject: Re: [Freeipa-users] Sudo works for full access, but not on
>>>>> a per command or host level.
>>>>>
>>>>> On 10/17/2012 11:13 AM, Macklin, Jason wrote:
>>>>>
>>>>>> None of my users have an LDAP password being requested by running
>>>>>> that command (except the admin user).
>>>>>>
>>>>>> Does each user account require an ldap account to go along with
>>>>>> their login account? I just get the following over and over no
>>>>>> matter which account I switch in the command...
>>>>>>
>>>>>> [***@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory
>>>>>> manager" -W uid=admin \* krbPwdLockoutDuration ?
>>>>>> Enter LDAP Password:
>>>>>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
>>>>>> [***@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory
>>>>>> manager" -W uid=asteinfeld \* krbPwdLockoutDuration ?
>>>>>> Enter LDAP Password:
>>>>>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
>>>>>> [***@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory
>>>>>> manager" -W uid=jmacklin \* krbPwdLockoutDuration ?
>>>>>> Enter LDAP Password:
>>>>>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
>>>>>>
>>>>> You have to specify which server to talk to using the -H
>>>>> ldap://fqdn.of.host option.
>>>>>
>>>>> ______________________________**_________________
>>>>> Freeipa-users mailing list
>>>>> Freeipa-***@redhat.com
>>>>> https://www.redhat.com/**mailman/listinfo/freeipa-users<https://www.redhat.com/mailman/listinfo/freeipa-users>
>>>>>
>>>>>
>>
> ______________________________**_________________
> Freeipa-users mailing list
> Freeipa-***@redhat.com
> https://www.redhat.com/**mailman/listinfo/freeipa-users<https://www.redhat.com/mailman/listinfo/freeipa-users>
>
In case there is a bug I wanted to throw my hat in the ring because I am
having almost the same exact issue with my deployment of sudo. I setup a
sudo rule on the ipa server with a single sudo command (/bin/su), for all
hosts, for a specific usergroup (netops). DIdn't work for my netops
user. When I eliminated the specific sudo command and went for all sudo
commands it started to work for my netops user. So I decided to add a few
more hosts to test. However now with the 2 additional host no sudo
commands work on either of these two hosts.

David
Rich Megginson
2012-10-17 18:01:45 UTC
Permalink
On 10/17/2012 11:21 AM, Macklin, Jason wrote:
> ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W uid=asteinfeld \* krbPwdLockoutDuration ?
> Enter LDAP Password:
> ldap_bind: Invalid credentials (49)
>
> I know this user password
user password? It's asking you for the directory manager password.
> because I reset it for the purpose of troubleshooting this issue with that account. I also get the same response when I use the admin account of my own account.
You get Invalid credentials (49)?
>
> -----Original Message-----
> From: Rich Megginson [mailto:***@redhat.com]
> Sent: Wednesday, October 17, 2012 1:15 PM
> To: Macklin, Jason {DASB~Branford}
> Cc: ***@redhat.com; freeipa-***@redhat.com
> Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
>
> On 10/17/2012 11:13 AM, Macklin, Jason wrote:
>> None of my users have an LDAP password being requested by running that command (except the admin user).
>>
>> Does each user account require an ldap account to go along with their login account? I just get the following over and over no matter which account I switch in the command...
>>
>> [***@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=admin \* krbPwdLockoutDuration ?
>> Enter LDAP Password:
>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
>> [***@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=asteinfeld \* krbPwdLockoutDuration ?
>> Enter LDAP Password:
>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
>> [***@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=jmacklin \* krbPwdLockoutDuration ?
>> Enter LDAP Password:
>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
> You have to specify which server to talk to using the -H ldap://fqdn.of.host option.
Dmitri Pal
2012-10-17 15:55:38 UTC
Permalink
On 10/17/2012 09:26 AM, Macklin, Jason wrote:
> Okay,
>
> Rule name: test4
> Enabled: TRUE
> Command category: all
> Users: asteinfeld
> Hosts: dbduwdu062.dbr.roche.com
> Host Groups: tempsudo
>
> Client dbduwdu062 is matched in the rule by both the hosts and groups entry.
>
> /etc/nsswitch.conf has:
>
> Netgroups: files sss
>
> Getent netgroup tempsudo returns:
>
> [***@dbduwdu062 Desktop]$ getent netgroup tempsudo
> tempsudo (dbduwdu063.dbr.roche.com, -, dbr.roche.com) (dbduwdu062.dbr.roche.com, -, dbr.roche.com)
>
> To the previous ldapsearch request:
>
> [***@dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com "ou=SUDOers,dc=dbr,dc=roche,dc=com"
> SASL/GSSAPI authentication started
> ldap_sasl_interactive_bind_s: Server is unwilling to perform (53)
> additional info: Entry permanently locked.

It seems that you tried the wrong password and the account is now
temporarily locked thus the server is unwilling to perform
authentication for this account.

>
> I am still scratching my head on this one...
>
> Cheers,
> Jason
>
> If you look closely, the reason that your admin works is because it appears to be matching a sudo rule who has the "ALL" hosts value set.
>
> When you run the non working user, it is attempting to match the hostname/hostgroup to the rule and fails to do so.
>
> Try this. Type: getent netgroup hostgroupname <- your host's hostgroup goes there.
>
> ^ that command should return all of the hosts in your hostgroup. If it does not, then check /etc/nsswitch.conf and make sure that netgroup is set to use sss.
>
> You will also need to make sure that the output of: domainname or nisdomainname matches your expected domain.
>
> Let me know how things look after trying that.
>


--
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
Macklin, Jason
2012-10-17 16:33:58 UTC
Permalink
ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com "ou=SUDOers,dc=dbr,dc=roche,dc=com"
SASL/GSSAPI authentication started
SASL username: ***@DBR.ROCHE.COM
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <> (default) with scope subtree
# filter: ou=SUDOers,dc=dbr,dc=roche,dc=com
# requesting: ALL
#

# search result
search: 4
result: 32 No such object

# numResponses: 1

Different response, but still no success with the non-working account.

Cheers,
Jason

-----Original Message-----
From: Dmitri Pal [mailto:***@redhat.com]
Sent: Wednesday, October 17, 2012 11:56 AM
To: Macklin, Jason {DASB~Branford}
Cc: ***@citrix.com; freeipa-***@redhat.com
Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.

On 10/17/2012 09:26 AM, Macklin, Jason wrote:
> Okay,
>
> Rule name: test4
> Enabled: TRUE
> Command category: all
> Users: asteinfeld
> Hosts: dbduwdu062.dbr.roche.com
> Host Groups: tempsudo
>
> Client dbduwdu062 is matched in the rule by both the hosts and groups entry.
>
> /etc/nsswitch.conf has:
>
> Netgroups: files sss
>
> Getent netgroup tempsudo returns:
>
> [***@dbduwdu062 Desktop]$ getent netgroup tempsudo
> tempsudo (dbduwdu063.dbr.roche.com, -, dbr.roche.com) (dbduwdu062.dbr.roche.com, -, dbr.roche.com)
>
> To the previous ldapsearch request:
>
> [***@dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com "ou=SUDOers,dc=dbr,dc=roche,dc=com"
> SASL/GSSAPI authentication started
> ldap_sasl_interactive_bind_s: Server is unwilling to perform (53)
> additional info: Entry permanently locked.

It seems that you tried the wrong password and the account is now temporarily locked thus the server is unwilling to perform authentication for this account.

>
> I am still scratching my head on this one...
>
> Cheers,
> Jason
>
> If you look closely, the reason that your admin works is because it appears to be matching a sudo rule who has the "ALL" hosts value set.
>
> When you run the non working user, it is attempting to match the hostname/hostgroup to the rule and fails to do so.
>
> Try this. Type: getent netgroup hostgroupname <- your host's hostgroup goes there.
>
> ^ that command should return all of the hosts in your hostgroup. If it does not, then check /etc/nsswitch.conf and make sure that netgroup is set to use sss.
>
> You will also need to make sure that the output of: domainname or nisdomainname matches your expected domain.
>
> Let me know how things look after trying that.
>


--
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
Dmitri Pal
2012-10-17 16:58:28 UTC
Permalink
On 10/17/2012 12:33 PM, Macklin, Jason wrote:
> ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com "ou=SUDOers,dc=dbr,dc=roche,dc=com"

You are missing -b

ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com -b
"ou=SUDOers,dc=dbr,dc=roche,dc=com"
Currently the command treats it as filter and thus returns no results.

I am asking you to run this command to see what LDAP data the server
presents to the client.
Running this would not cure the problem but rather might give more hints
of what the actual problem is.
> SASL/GSSAPI authentication started
> SASL username: ***@DBR.ROCHE.COM
> SASL SSF: 56
> SASL data security layer installed.
> # extended LDIF
> #
> # LDAPv3
> # base <> (default) with scope subtree
> # filter: ou=SUDOers,dc=dbr,dc=roche,dc=com
> # requesting: ALL
> #
>
> # search result
> search: 4
> result: 32 No such object
>
> # numResponses: 1
>
> Different response, but still no success with the non-working account.
>
> Cheers,
> Jason
>
> -----Original Message-----
> From: Dmitri Pal [mailto:***@redhat.com]
> Sent: Wednesday, October 17, 2012 11:56 AM
> To: Macklin, Jason {DASB~Branford}
> Cc: ***@citrix.com; freeipa-***@redhat.com
> Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
>
> On 10/17/2012 09:26 AM, Macklin, Jason wrote:
>> Okay,
>>
>> Rule name: test4
>> Enabled: TRUE
>> Command category: all
>> Users: asteinfeld
>> Hosts: dbduwdu062.dbr.roche.com
>> Host Groups: tempsudo
>>
>> Client dbduwdu062 is matched in the rule by both the hosts and groups entry.
>>
>> /etc/nsswitch.conf has:
>>
>> Netgroups: files sss
>>
>> Getent netgroup tempsudo returns:
>>
>> [***@dbduwdu062 Desktop]$ getent netgroup tempsudo
>> tempsudo (dbduwdu063.dbr.roche.com, -, dbr.roche.com) (dbduwdu062.dbr.roche.com, -, dbr.roche.com)
>>
>> To the previous ldapsearch request:
>>
>> [***@dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com "ou=SUDOers,dc=dbr,dc=roche,dc=com"
>> SASL/GSSAPI authentication started
>> ldap_sasl_interactive_bind_s: Server is unwilling to perform (53)
>> additional info: Entry permanently locked.
> It seems that you tried the wrong password and the account is now temporarily locked thus the server is unwilling to perform authentication for this account.
>
>> I am still scratching my head on this one...
>>
>> Cheers,
>> Jason
>>
>> If you look closely, the reason that your admin works is because it appears to be matching a sudo rule who has the "ALL" hosts value set.
>>
>> When you run the non working user, it is attempting to match the hostname/hostgroup to the rule and fails to do so.
>>
>> Try this. Type: getent netgroup hostgroupname <- your host's hostgroup goes there.
>>
>> ^ that command should return all of the hosts in your hostgroup. If it does not, then check /etc/nsswitch.conf and make sure that netgroup is set to use sss.
>>
>> You will also need to make sure that the output of: domainname or nisdomainname matches your expected domain.
>>
>> Let me know how things look after trying that.
>>
>
> --
> Thank you,
> Dmitri Pal
>
> Sr. Engineering Manager for IdM portfolio Red Hat Inc.
>
>
> -------------------------------
> Looking to carve out IT costs?
> www.redhat.com/carveoutcosts/
>
>
>


--
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
Macklin, Jason
2012-10-17 17:05:37 UTC
Permalink
Thanks guys! Adding the "-b" did make a world of difference though it still doesn't make anything too obvious... at least to me.

[***@dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com -b "ou=SUDOers,dc=dbr,dc=roche,dc=com"
SASL/GSSAPI authentication started
SASL username: ***@DBR.ROCHE.COM
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <ou=SUDOers,dc=dbr,dc=roche,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# sudoers, dbr.roche.com
dn: ou=sudoers,dc=dbr,dc=roche,dc=com
objectClass: extensibleObject
ou: sudoers

# test4, sudoers, dbr.roche.com
dn: cn=test4,ou=sudoers,dc=dbr,dc=roche,dc=com
objectClass: sudoRole
sudoUser: asteinfeld
sudoHost: dbduwdu062.dbr.roche.com
sudoHost: +tempsudo
sudoCommand: ALL
cn: test4

# switch, sudoers, dbr.roche.com
dn: cn=switch,ou=sudoers,dc=dbr,dc=roche,dc=com
objectClass: sudoRole
sudoUser: oyilmaz
sudoHost: dbdusdu071.dbr.roche.com
sudoCommand: /bin/su
cn: switch

# jing144, sudoers, dbr.roche.com
dn: cn=jing144,ou=sudoers,dc=dbr,dc=roche,dc=com
objectClass: sudoRole
sudoUser: jli
sudoHost: dbduvdu144.dbr.roche.com
sudoCommand: ALL
cn: jing144

# Admin, sudoers, dbr.roche.com
dn: cn=Admin,ou=sudoers,dc=dbr,dc=roche,dc=com
objectClass: sudoRole
sudoUser: jmacklin
sudoUser: mrini
sudoUser: cgajare
sudoUser: parnold
sudoUser: hhebert
sudoUser: ckuecherer
sudoUser: gferreri
sudoHost: ALL
sudoCommand: ALL
cn: Admin

# search result
search: 4
result: 0 Success

# numResponses: 6
# numEntries: 5

I really appreciate all of the help!

Cheers,
Jason
Dmitri Pal
2012-10-17 18:57:11 UTC
Permalink
On 10/17/2012 01:05 PM, Macklin, Jason wrote:
> Thanks guys! Adding the "-b" did make a world of difference though it still doesn't make anything too obvious... at least to me.
>
> [***@dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com -b "ou=SUDOers,dc=dbr,dc=roche,dc=com"
> SASL/GSSAPI authentication started
> SASL username: ***@DBR.ROCHE.COM
> SASL SSF: 56
> SASL data security layer installed.
> # extended LDIF
> #
> # LDAPv3
> # base <ou=SUDOers,dc=dbr,dc=roche,dc=com> with scope subtree
> # filter: (objectclass=*)
> # requesting: ALL
> #
>
> # sudoers, dbr.roche.com
> dn: ou=sudoers,dc=dbr,dc=roche,dc=com
> objectClass: extensibleObject
> ou: sudoers
>
> # test4, sudoers, dbr.roche.com
> dn: cn=test4,ou=sudoers,dc=dbr,dc=roche,dc=com
> objectClass: sudoRole
> sudoUser: asteinfeld
> sudoHost: dbduwdu062.dbr.roche.com
> sudoHost: +tempsudo
> sudoCommand: ALL
> cn: test4

This means that user "asteinfeld" should be allowed to execute any
command on host "dbduwdu062.dbr.roche.com" or any host that is a member
of the "tempsudo" host group.
Is this the user you making tests with?

Keep in mind the other general per-requisits: If you use netgroups the
domain should be correct and the netgroups should be configured.
Also HBAC should allow this user to authenticate via sudo on this host.
AFAIR your HBAC is now wide open but when you start changing things to
narrow access you need to make HBAC rules for SUDO too.
>
> # switch, sudoers, dbr.roche.com
> dn: cn=switch,ou=sudoers,dc=dbr,dc=roche,dc=com
> objectClass: sudoRole
> sudoUser: oyilmaz
> sudoHost: dbdusdu071.dbr.roche.com
> sudoCommand: /bin/su
> cn: switch

This rule allows "oyilmaz" to execute one command "/bin/su" on host
"dbdusdu071.dbr.roche.com"
>
> # jing144, sudoers, dbr.roche.com
> dn: cn=jing144,ou=sudoers,dc=dbr,dc=roche,dc=com
> objectClass: sudoRole
> sudoUser: jli
> sudoHost: dbduvdu144.dbr.roche.com
> sudoCommand: ALL
> cn: jing144

I hope you can now deduce the meaning of this one :-)

>
> # Admin, sudoers, dbr.roche.com
> dn: cn=Admin,ou=sudoers,dc=dbr,dc=roche,dc=com
> objectClass: sudoRole
> sudoUser: jmacklin
> sudoUser: mrini
> sudoUser: cgajare
> sudoUser: parnold
> sudoUser: hhebert
> sudoUser: ckuecherer
> sudoUser: gferreri
> sudoHost: ALL
> sudoCommand: ALL
> cn: Admin

given users ALL commands on any host.

> # search result
> search: 4
> result: 0 Success
>
> # numResponses: 6
> # numEntries: 5
>
> I really appreciate all of the help!
>
> Cheers,
> Jason
>

So with this knowledge can you try different combinations of users and
hosts and provide the results?
You might want to remove the Admin for now to get it out of picture.

--
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
Macklin, Jason
2012-10-17 19:05:15 UTC
Permalink
Yes Dmitri, this is the user I'm doing the tests with on that client. Though I would expect this user to have sudo capabilities on this host he does not. I first came across the idea that maybe domainname/nisdomainname/dnsdomainname did not match and that was causing the problem. I have since fixed all of those to match my system domain which is the same domain that the client was enrolled with and it did not change any of the sudo behaviors for this user. I currently have no specific HBAC rule configured besides the "wide open" rule. Do I need one more specific for allowing users to run sudo?

-----Original Message-----
From: Dmitri Pal [mailto:***@redhat.com]
Sent: Wednesday, October 17, 2012 2:57 PM
To: Macklin, Jason {DASB~Branford}
Cc: ***@citrix.com; freeipa-***@redhat.com
Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.

On 10/17/2012 01:05 PM, Macklin, Jason wrote:
> Thanks guys! Adding the "-b" did make a world of difference though it still doesn't make anything too obvious... at least to me.
>
> [***@dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com -b "ou=SUDOers,dc=dbr,dc=roche,dc=com"
> SASL/GSSAPI authentication started
> SASL username: ***@DBR.ROCHE.COM
> SASL SSF: 56
> SASL data security layer installed.
> # extended LDIF
> #
> # LDAPv3
> # base <ou=SUDOers,dc=dbr,dc=roche,dc=com> with scope subtree #
> filter: (objectclass=*) # requesting: ALL #
>
> # sudoers, dbr.roche.com
> dn: ou=sudoers,dc=dbr,dc=roche,dc=com
> objectClass: extensibleObject
> ou: sudoers
>
> # test4, sudoers, dbr.roche.com
> dn: cn=test4,ou=sudoers,dc=dbr,dc=roche,dc=com
> objectClass: sudoRole
> sudoUser: asteinfeld
> sudoHost: dbduwdu062.dbr.roche.com
> sudoHost: +tempsudo
> sudoCommand: ALL
> cn: test4

This means that user "asteinfeld" should be allowed to execute any command on host "dbduwdu062.dbr.roche.com" or any host that is a member of the "tempsudo" host group.
Is this the user you making tests with?

Keep in mind the other general per-requisits: If you use netgroups the domain should be correct and the netgroups should be configured.
Also HBAC should allow this user to authenticate via sudo on this host.
AFAIR your HBAC is now wide open but when you start changing things to narrow access you need to make HBAC rules for SUDO too.
>
> # switch, sudoers, dbr.roche.com
> dn: cn=switch,ou=sudoers,dc=dbr,dc=roche,dc=com
> objectClass: sudoRole
> sudoUser: oyilmaz
> sudoHost: dbdusdu071.dbr.roche.com
> sudoCommand: /bin/su
> cn: switch

This rule allows "oyilmaz" to execute one command "/bin/su" on host "dbdusdu071.dbr.roche.com"
>
> # jing144, sudoers, dbr.roche.com
> dn: cn=jing144,ou=sudoers,dc=dbr,dc=roche,dc=com
> objectClass: sudoRole
> sudoUser: jli
> sudoHost: dbduvdu144.dbr.roche.com
> sudoCommand: ALL
> cn: jing144

I hope you can now deduce the meaning of this one :-)

>
> # Admin, sudoers, dbr.roche.com
> dn: cn=Admin,ou=sudoers,dc=dbr,dc=roche,dc=com
> objectClass: sudoRole
> sudoUser: jmacklin
> sudoUser: mrini
> sudoUser: cgajare
> sudoUser: parnold
> sudoUser: hhebert
> sudoUser: ckuecherer
> sudoUser: gferreri
> sudoHost: ALL
> sudoCommand: ALL
> cn: Admin

given users ALL commands on any host.

> # search result
> search: 4
> result: 0 Success
>
> # numResponses: 6
> # numEntries: 5
>
> I really appreciate all of the help!
>
> Cheers,
> Jason
>

So with this knowledge can you try different combinations of users and hosts and provide the results?
You might want to remove the Admin for now to get it out of picture.

--
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
Dmitri Pal
2012-10-17 19:26:03 UTC
Permalink
On 10/17/2012 03:05 PM, Macklin, Jason wrote:
> Yes Dmitri, this is the user I'm doing the tests with on that client. Though I would expect this user to have sudo capabilities on this host he does not. I first came across the idea that maybe domainname/nisdomainname/dnsdomainname did not match and that was causing the problem. I have since fixed all of those to match my system domain which is the same domain that the client was enrolled with and it did not change any of the sudo behaviors for this user. I currently have no specific HBAC rule configured besides the "wide open" rule. Do I need one more specific for allowing users to run sudo?

No. It should just work then. It definitely connects and matches the
Admin rule but not the other rules so I was not sure if you are testing
the right rule on the right machine with the right user.

We can start dealing with the problems step by step.
We know Admin rule works.
If you add all hosts to a hostgroup and use it in the Admin rule instead
of just all would it continue to work?
Then you can start removing hosts from the group one by one.

After testing with group you can replace the group with individual host
and see whether it works and so on.
May be there is a bug somewhere but so far we have not narrowed it done
well enough.

I am traveling next day so I hope someone else will pickup the thread.

>
> -----Original Message-----
> From: Dmitri Pal [mailto:***@redhat.com]
> Sent: Wednesday, October 17, 2012 2:57 PM
> To: Macklin, Jason {DASB~Branford}
> Cc: ***@citrix.com; freeipa-***@redhat.com
> Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
>
> On 10/17/2012 01:05 PM, Macklin, Jason wrote:
>> Thanks guys! Adding the "-b" did make a world of difference though it still doesn't make anything too obvious... at least to me.
>>
>> [***@dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com -b "ou=SUDOers,dc=dbr,dc=roche,dc=com"
>> SASL/GSSAPI authentication started
>> SASL username: ***@DBR.ROCHE.COM
>> SASL SSF: 56
>> SASL data security layer installed.
>> # extended LDIF
>> #
>> # LDAPv3
>> # base <ou=SUDOers,dc=dbr,dc=roche,dc=com> with scope subtree #
>> filter: (objectclass=*) # requesting: ALL #
>>
>> # sudoers, dbr.roche.com
>> dn: ou=sudoers,dc=dbr,dc=roche,dc=com
>> objectClass: extensibleObject
>> ou: sudoers
>>
>> # test4, sudoers, dbr.roche.com
>> dn: cn=test4,ou=sudoers,dc=dbr,dc=roche,dc=com
>> objectClass: sudoRole
>> sudoUser: asteinfeld
>> sudoHost: dbduwdu062.dbr.roche.com
>> sudoHost: +tempsudo
>> sudoCommand: ALL
>> cn: test4
> This means that user "asteinfeld" should be allowed to execute any command on host "dbduwdu062.dbr.roche.com" or any host that is a member of the "tempsudo" host group.
> Is this the user you making tests with?
>
> Keep in mind the other general per-requisits: If you use netgroups the domain should be correct and the netgroups should be configured.
> Also HBAC should allow this user to authenticate via sudo on this host.
> AFAIR your HBAC is now wide open but when you start changing things to narrow access you need to make HBAC rules for SUDO too.
>> # switch, sudoers, dbr.roche.com
>> dn: cn=switch,ou=sudoers,dc=dbr,dc=roche,dc=com
>> objectClass: sudoRole
>> sudoUser: oyilmaz
>> sudoHost: dbdusdu071.dbr.roche.com
>> sudoCommand: /bin/su
>> cn: switch
> This rule allows "oyilmaz" to execute one command "/bin/su" on host "dbdusdu071.dbr.roche.com"
>> # jing144, sudoers, dbr.roche.com
>> dn: cn=jing144,ou=sudoers,dc=dbr,dc=roche,dc=com
>> objectClass: sudoRole
>> sudoUser: jli
>> sudoHost: dbduvdu144.dbr.roche.com
>> sudoCommand: ALL
>> cn: jing144
> I hope you can now deduce the meaning of this one :-)
>
>> # Admin, sudoers, dbr.roche.com
>> dn: cn=Admin,ou=sudoers,dc=dbr,dc=roche,dc=com
>> objectClass: sudoRole
>> sudoUser: jmacklin
>> sudoUser: mrini
>> sudoUser: cgajare
>> sudoUser: parnold
>> sudoUser: hhebert
>> sudoUser: ckuecherer
>> sudoUser: gferreri
>> sudoHost: ALL
>> sudoCommand: ALL
>> cn: Admin
> given users ALL commands on any host.
>
>> # search result
>> search: 4
>> result: 0 Success
>>
>> # numResponses: 6
>> # numEntries: 5
>>
>> I really appreciate all of the help!
>>
>> Cheers,
>> Jason
>>
> So with this knowledge can you try different combinations of users and hosts and provide the results?
> You might want to remove the Admin for now to get it out of picture.
>
> --
> Thank you,
> Dmitri Pal
>
> Sr. Engineering Manager for IdM portfolio Red Hat Inc.
>
>
> -------------------------------
> Looking to carve out IT costs?
> www.redhat.com/carveoutcosts/
>
>
>


--
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
Rob Crittenden
2012-10-17 19:44:12 UTC
Permalink
Can you confirm that you have sudoer_debug set to 2?

If I gather correctly, this is on RHEL 6.3? What version of sudo?

I'm seeing different output. Mine includes the number of candidate
results for sudoUser are found.

If you watch /var/log/dirsrv/slapd-REALM/access on your IPA server
you'll be able to see the LDAP searches the sudo client is making. The
log is buffered so you won't see them immediately. Can you send us the
queries that are being made?

thanks

rob
Macklin, Jason
2012-10-18 11:48:58 UTC
Permalink
Update with success! (but embarrassment)

I apologize for putting everyone through the ringer on this one. Here is what I found.

I mentioned at one point that my domainname/nisdomainname/dnsdomainname did not all return my correct domain, but that I had fixed this. As it turned out, I had a typo in my rc.local file. Fixing them so they return the correct value is not enough to fix sudo. I ran ipa-client --uninstall -->> yum remove ipa-client -->> yum install ipa-client -->> ipa-client-install and re-enrolled my client without making any other changes. Apparently, something does not translate properly during the enroll process if your domain is not set properly in the rc.local file. Everything is now working just as I would expect it to!

Again, thank you everyone for your assistance!

Cheers,
Jason

-----Original Message-----
From: Rob Crittenden [mailto:***@redhat.com]
Sent: Wednesday, October 17, 2012 3:44 PM
To: Macklin, Jason {DASB~Branford}
Cc: ***@redhat.com; freeipa-***@redhat.com
Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.

Can you confirm that you have sudoer_debug set to 2?

If I gather correctly, this is on RHEL 6.3? What version of sudo?

I'm seeing different output. Mine includes the number of candidate results for sudoUser are found.

If you watch /var/log/dirsrv/slapd-REALM/access on your IPA server you'll be able to see the LDAP searches the sudo client is making. The log is buffered so you won't see them immediately. Can you send us the queries that are being made?

thanks

rob
Rich Megginson
2012-10-17 16:58:42 UTC
Permalink
On 10/17/2012 10:33 AM, Macklin, Jason wrote:
> ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com "ou=SUDOers,dc=dbr,dc=roche,dc=com"
> SASL/GSSAPI authentication started
> SASL username: ***@DBR.ROCHE.COM
> SASL SSF: 56
> SASL data security layer installed.
> # extended LDIF
> #
> # LDAPv3
> # base<> (default) with scope subtree
> # filter: ou=SUDOers,dc=dbr,dc=roche,dc=com
> # requesting: ALL
> #
>
> # search result
> search: 4
> result: 32 No such object
>
> # numResponses: 1
>
> Different response, but still no success with the non-working account.

Sorry - the ldapsearch command is wrong. Try this:
ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com -b
"ou=SUDOers,dc=dbr,dc=roche,dc=com"

>
> Cheers,
> Jason
>
> -----Original Message-----
> From: Dmitri Pal [mailto:***@redhat.com]
> Sent: Wednesday, October 17, 2012 11:56 AM
> To: Macklin, Jason {DASB~Branford}
> Cc: ***@citrix.com; freeipa-***@redhat.com
> Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
>
> On 10/17/2012 09:26 AM, Macklin, Jason wrote:
>> Okay,
>>
>> Rule name: test4
>> Enabled: TRUE
>> Command category: all
>> Users: asteinfeld
>> Hosts: dbduwdu062.dbr.roche.com
>> Host Groups: tempsudo
>>
>> Client dbduwdu062 is matched in the rule by both the hosts and groups entry.
>>
>> /etc/nsswitch.conf has:
>>
>> Netgroups: files sss
>>
>> Getent netgroup tempsudo returns:
>>
>> [***@dbduwdu062 Desktop]$ getent netgroup tempsudo
>> tempsudo (dbduwdu063.dbr.roche.com, -, dbr.roche.com) (dbduwdu062.dbr.roche.com, -, dbr.roche.com)
>>
>> To the previous ldapsearch request:
>>
>> [***@dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com "ou=SUDOers,dc=dbr,dc=roche,dc=com"
>> SASL/GSSAPI authentication started
>> ldap_sasl_interactive_bind_s: Server is unwilling to perform (53)
>> additional info: Entry permanently locked.
> It seems that you tried the wrong password and the account is now temporarily locked thus the server is unwilling to perform authentication for this account.
>
>> I am still scratching my head on this one...
>>
>> Cheers,
>> Jason
>>
>> If you look closely, the reason that your admin works is because it appears to be matching a sudo rule who has the "ALL" hosts value set.
>>
>> When you run the non working user, it is attempting to match the hostname/hostgroup to the rule and fails to do so.
>>
>> Try this. Type: getent netgroup hostgroupname<- your host's hostgroup goes there.
>>
>> ^ that command should return all of the hosts in your hostgroup. If it does not, then check /etc/nsswitch.conf and make sure that netgroup is set to use sss.
>>
>> You will also need to make sure that the output of: domainname or nisdomainname matches your expected domain.
>>
>> Let me know how things look after trying that.
>>
>
> --
> Thank you,
> Dmitri Pal
>
> Sr. Engineering Manager for IdM portfolio Red Hat Inc.
>
>
> -------------------------------
> Looking to carve out IT costs?
> www.redhat.com/carveoutcosts/
>
>
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-***@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
Steven Jones
2012-10-15 21:14:05 UTC
Permalink
Hi,

my 2 cents,

2 possibilities,

1) There should I think be a HBAC rule and a sudo rule pair, I think you need both. For the HBAC rule with limited permissions you need the sudo privaledge and access say ssh and /or login, so at least 2, so when you say "1" it might be that? I dont know how you are getting access, it sounds possible.

2) or you have the bug I have it looks possible as well,

Are you putting the host into a host group and using that host group in the sudo rule?

There is a bug that stops that working, so in the sudo rule delete the host group and add the server server/host itself and see if that works.

If so you have the bug, I find deleting the HBAC and sudo rules and starting again from scratch sometimes works, sometimes doesnt. I have 30~50% of my sudo rules with individial hosts and not groups because of this.

If your problem is like mine, and you have RH support on RHEL? then raise a case, my one is #6963677 so I'd ask for it to be linked but its been open since August.

:/


regards

Steven Jones

Technical Specialist - Linux RHCE

Victoria University, Wellington, NZ

0064 4 463 6272

________________________________
From: freeipa-users-***@redhat.com [freeipa-users-***@redhat.com] on behalf of Macklin, Jason [***@roche.com]
Sent: Tuesday, 16 October 2012 9:34 a.m.
To: freeipa-***@redhat.com
Subject: [Freeipa-users] Sudo works for full access, but not on a per command or host level.

Hi,

I apologize up front if this is obvious, but I’m having issues configuring sudo privileges.

I currently have an IPA server running FreeIPA 2.2 with sudo configured for our administrators on all hosts. This works fantastic! As soon as I attempt to configure a more specific sudo rule it does not work. In my troubleshooting, I have noticed that from the same host my admin level privileges work, but with another user account setup to just run one command, it fails. I have turned on sudo debugging and the only thing I can find that looks out of sorts is the following:

sudo: host_matches=0

As soon as I move the user account that is failing into the admin group it starts to work.

I have attempted every iteration of sudo configuration on the server that I can think of. I have setup HBAC and given that a shot as well. At this point I’m completely stumped and would appreciate any help that I can get!

Thank you in advance for your assistance,
Jason
Continue reading on narkive:
Loading...