Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
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:rcrit...@redhat.com]
Sent: Wednesday, October 17, 2012 3:44 PM
To: Macklin, Jason {DASB~Branford}
Cc: d...@redhat.com; freeipa-users@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
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
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: [jmacklin@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: [jmacklin@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. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
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: [jmacklin@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: [jmacklin@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-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com
ou=SUDOers,dc=dbr,dc=roche,dc=com
SASL/GSSAPI authentication started
SASL username: ad...@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:d...@redhat.com]
Sent: Wednesday, October 17, 2012 11:56 AM
To: Macklin, Jason {DASB~Branford}
Cc: jr.aqu...@citrix.com; freeipa-users@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:
[jmacklin@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:
[jmacklin@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-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
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: [jmacklin@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: [jmacklin@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 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
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:
[jmacklin@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:
[jmacklin@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.
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
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: ad...@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:d...@redhat.com]
Sent: Wednesday, October 17, 2012 11:56 AM
To: Macklin, Jason {DASB~Branford}
Cc: jr.aqu...@citrix.com; freeipa-users@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:
[jmacklin@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:
[jmacklin@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/
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
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: ad...@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:d...@redhat.com]
Sent: Wednesday, October 17, 2012 11:56 AM
To: Macklin, Jason {DASB~Branford}
Cc: jr.aqu...@citrix.com; freeipa-users@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:
[jmacklin@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:
[jmacklin@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-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
Thanks guys! Adding the -b did make a world of difference though it still doesn't make anything too obvious... at least to me. [jmacklin@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: ad...@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 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
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... [jmacklin@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) [jmacklin@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) [jmacklin@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) ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
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... [jmacklin@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) [jmacklin@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) [jmacklin@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-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
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:rmegg...@redhat.com]
Sent: Wednesday, October 17, 2012 1:15 PM
To: Macklin, Jason {DASB~Branford}
Cc: s...@redhat.com; freeipa-users@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...
[jmacklin@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)
[jmacklin@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)
[jmacklin@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-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
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:rmegg...@redhat.com]
Sent: Wednesday, October 17, 2012 1:15 PM
To: Macklin, Jason {DASB~Branford}
Cc: s...@redhat.com; freeipa-users@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...
[jmacklin@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)
[jmacklin@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)
[jmacklin@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-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
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:rcrit...@redhat.com]
Sent: Wednesday, October 17, 2012 1:37 PM
To: Macklin, Jason {DASB~Branford}
Cc: rmegg...@redhat.com; freeipa-users@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:rmegg...@redhat.com]
Sent: Wednesday, October 17, 2012 1:15 PM
To: Macklin, Jason {DASB~Branford}
Cc: s...@redhat.com; freeipa-users@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...
[jmacklin@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)
[jmacklin@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)
[jmacklin@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-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
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:rcrit...@redhat.com]
Sent: Wednesday, October 17, 2012 1:37 PM
To: Macklin, Jason {DASB~Branford}
Cc: rmegg...@redhat.com; freeipa-users@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:rmegg...@redhat.com]
Sent: Wednesday, October 17, 2012 1:15 PM
To: Macklin, Jason {DASB~Branford}
Cc: s...@redhat.com; freeipa-users@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...
[jmacklin@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)
[jmacklin@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)
[jmacklin@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-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
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: asteinf...@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 [jmacklin@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: jmack...@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
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. [jmacklin@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: ad...@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/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
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:d...@redhat.com]
Sent: Wednesday, October 17, 2012 2:57 PM
To: Macklin, Jason {DASB~Branford}
Cc: jr.aqu...@citrix.com; freeipa-users@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.
[jmacklin@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: ad...@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/
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
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: asteinf...@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.
[jmacklin@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: jmack...@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: 2012101718Z
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:rmegg...@redhat.com]
Sent: Wednesday, October 17, 2012 2:06 PM
To: Macklin, Jason {DASB~Branford}
Cc: rcrit...@redhat.com; freeipa-users@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:
Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
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:d...@redhat.com]
Sent: Wednesday, October 17, 2012 2:57 PM
To: Macklin, Jason {DASB~Branford}
Cc: jr.aqu...@citrix.com; freeipa-users@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.
[jmacklin@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: ad...@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/
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
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: asteinf...@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.
[jmacklin@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: jmack...@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: 2012101718Z
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:rmegg...@redhat.com]
Sent: Wednesday, October 17, 2012 2:06 PM
To: Macklin, Jason {DASB~Branford}
Cc: rcrit...@redhat.com; freeipa-users@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 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
On Wed, Oct 17, 2012 at 2:26 PM, Rob Crittenden rcrit...@redhat.com wrote: Rich Megginson wrote: On 10/17/2012 12:49 PM, Macklin, Jason wrote: ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.**comhttp://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: asteinf...@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. [jmacklin@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: jmack...@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: 2012101718Z 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
Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
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-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Dmitri Pal Sent: Monday, October 15, 2012 5:58 PM To: freeipa-users@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-users@redhat.commailto:Freeipa-users@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-users@redhat.commailto:Freeipa-users@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-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
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-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] *On Behalf Of *Dmitri Pal *Sent:* Monday, October 15, 2012 5:58 PM *To:* freeipa-users@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-users@redhat.com mailto:Freeipa-users@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-users@redhat.com mailto:Freeipa-users@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-users@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-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
Dmitri, I will give you everything I've got. If I can provide something else, let me know! Working User: Sudo debug output: [jmacklin@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: [asteinfeld@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-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Dmitri Pal Sent: Tuesday, October 16, 2012 10:33 AM To: freeipa-users@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-boun...@redhat.commailto:freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Dmitri Pal Sent: Monday, October 15, 2012 5:58 PM To: freeipa-users@redhat.commailto:freeipa-users@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,
Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
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=comSASL/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 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
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-users@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-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
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-boun...@redhat.com [freeipa-users-boun...@redhat.com] on behalf of Macklin, Jason [jason.mack...@roche.com] Sent: Tuesday, 16 October 2012 9:34 a.m. To: freeipa-users@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 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
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-users@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-users@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-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
