Re: [Freeipa-users] regex with sudo commands

[Pavel Březina]

On 05/05/2015 10:53 AM, Martin Kosek wrote:

On 05/05/2015 03:37 AM, Megan . wrote:

Good Evening!

I'm running 3.0.0-42 on Centos 6.6.

I setup a number of sudo commands today with regular expressions and
now users seem to be having issues running any sudo command.  Are
there any known issues with having regex in sudo commands within the
IPA server?

Here is an example of a sudo rule I have setup.  When my user runs
sudo -ll he only sees the below command, and he should have a large
number of commands available (like /sbin/service httpd restart)

SSSD Role: deploy for UAT
 RunAsUsers: appusr
 Commands:
/usr/bin/python /usr/share/appusr/onworld-tools/scripts/configure.py
-l [a-zA-Z0-9\-_/]* -e EPSG[0-9][0-9][0-9][0-9] -t [a-z]*
/usr/share/appusr/apache-ant-1.9.4/bin/ant -f
/usr/share/appusr/onworld-tools/scripts/config_deploy.xml
deploy-[a-zA-Z0-9\-]  -Denv=uat


I also purged /var/lib/sss/db and restated sssd thinking it might be
related to caching but it didn't help.

Thanks in advance!



CCing Pavel Brezina for reference as the sudo guru, but I think he will miss
more information for your bug. For example, it would help to show the SUDO
commands for IPA that should be applied for the respective users:

$ ipa sudorule-show ...

Martin



I believe Tomas already provided the correct answer.

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Sudo hangs after reenrollment of some servers in fresh IPA domain

[Pavel Březina]

On 06/05/2015 03:14 PM, Sina Owolabi wrote:

Odd, sssd sudo up and started working properly after I added debug to
the clients I was interested in.
I didnt see any errors in the logs at all.


This may indicate a race condition. Does it hang up again if you disable 
debugging?




Very strange. Thanks everyone.

On Thu, Jun 4, 2015 at 7:36 PM, Pavel Brezina  wrote:

Hi,
please put the following line to /etc/sudo.conf to obtain sudo logs and send us 
the file:
Debug sudo /var/log/sudo_debug all@trace

- Original Message -

From: "Martin Kosek" 
To: "Sina Owolabi" 
Cc: "Cory Carlton" , freeipa-users@redhat.com, "Pavel Brezina" 
, "Jakub
Hrozek" 
Sent: Thursday, June 4, 2015 5:15:04 PM
Subject: Re: [Freeipa-users] Sudo hangs after reenrollment of some servers in 
fresh IPA domain

On 06/04/2015 05:13 PM, Sina Owolabi wrote:

Hi Martin

I have deleted everything in /var/lib/sss/db/ and restarted sssd,
no luck.


In that case, I am afraid you might need to enable sudo and SSSD debug
(https://fedorahosted.org/sssd/wiki/Troubleshooting) and see where it hans.
Also CCing sudo/sssd SMEs to be aware.



On Thu, Jun 4, 2015 at 4:10 PM, Martin Kosek  wrote:

On 06/04/2015 05:06 PM, Cory Carlton wrote:

I would check for DNS resolution from the machine executing the sudo, to
the IPA server.


I would also suggest cleaning SSSD caches, since you reinstalled against
the
same domain, but actually different server (/var/lib/sss/db/)


On Thu, Jun 4, 2015 at 9:54 AM, Sina Owolabi 
wrote:


Hi

I recently had to remove and reinstall a fresh IPA server. I am
currently re-enrolling all the ipa clients to the recently refreshed
domain (same name as the previous realm and domain). The new IPA
master is RHEL7.1 with IPA 4.1.3.

All client servers are running RHEL6.6.

I also have sudorule that allows a group to have access to run all
commands on all servers:

   Rule name: All
   Enabled: TRUE
   Host category: all
   Command category: all
   User Groups: superusers
   Sudo Option: !authenticate


I noticed that trying to run sudo on a few of the servers makes the
command hang indefinitely.
I am not sure what is the cause and where to look. Please what can I
do to troubleshoot and fix this?

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project












--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeIPA and sudo Defaults

[Pavel Březina]

On 08/04/2015 11:57 AM, Innes, Duncan wrote:

Hi folks,
Struggling with creating a sudo rule in IPA that will allow my
foreman-proxy to run specific commands.  When I put the following into
/etc/sudoers.d/foreman:
[root@puppet01 ~]# cat /etc/sudoers.d/foreman
foreman-proxy ALL = NOPASSWD: /usr/bin/puppet cert *, /usr/bin/puppet kick *
Defaults:foreman-proxy !requiretty
innesd ALL = NOPASSWD: /usr/bin/puppet cert *, /usr/bin/puppet kick *
Defaults:innesd !requiretty
[root@puppet01 ~]#

[innesd@puppet01 ~]$ sudo -l
Matching Defaults entries for innesd on this host:
!requiretty
User innesd may run the following commands on this host:
 (root) NOPASSWD: /usr/bin/puppet cert *, (root) /usr/bin/puppet kick *
 (root) /bin/su
[innesd@puppet01 ~]$
Both my user and the foreman-proxy can run the relevant commands both on
the command line and remotely.
IT Security are not happy with local sudo rules being condifured around
the network, so I'm trying to create the same configuration via IPA.
When I try to get the same rule into IPA, my user can run the command in
a tty, but the foreman-proxy user is refused.  This looks to be down to
the lack of !requiretty coming through for the users:
[root@ipa01 ~]# ipa sudorule-show foreman-proxy
   Rule name: foreman-proxy
Enabled: TRUE
   User category: all
   Hosts: puppet02.example.com, puppet01.example.com,
puppet03.example.com, puppet04.example.com
   Sudo Allow Commands: /usr/bin/puppet cert *, /usr/bin/puppet kick *
   Sudo Option: !authenticate, !requiretty
[root@ipa01 ~]#
and once I've removed the #includedir option from my local sudoers file,
I get the following as my user:
[innesd@puppet01 ~]$ sudo -l
User innesd may run the following commands on this host:
 (root) /bin/su
 (root) NOPASSWD: /usr/bin/puppet cert *, /usr/bin/puppet kick *
[innesd@puppet01 ~]$
where the noticeable difference is that the !requiretty isn't listed
under any "Matching Defaults entries" for my user.  With the rule set up
like this, I can run the command in a tty, but the foreman-proxy user is
denied when the command is run without a tty.
How do I go about setting the Defaults for the foreman-proxy user?  Once
my testing is done, I'd like to move the rule to run only against the
foreman-proxy external user rather than all users.


Can you also provide sudo logs please?


And a small follow-up question: how long should I expect it to take for
a change to the sudo rule on my IPA server to become available on the
client?  I keep doing sss_cache -E to clear the cache, but it still
seems to take it's own sweet time to be changed on the client.  It's not
a huge wait - just a bit of a pain when I'm testing these changes.


Please, set entry_cache_sudo_timeout = 0 in your domain for testing 
purpose. You can also look at ldap_sudo_full_refresh_interval and 
ldap_sudo_smart_refresh_interval that says how often sssd searches for 
new/modified rules.



Thanks in advance,
Duncan Innes


--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Sudo entry not found by sssd in the cache db

[Pavel Březina]

On 09/09/2015 09:31 PM, Molnár Domokos wrote:

I have a working IPA server and a working client config on an OpenSuse
13.2 with the following versions:
nappali:~ # rpm -qa |grep sssd
sssd-tools-1.12.2-3.4.1.i586
sssd-krb5-1.12.2-3.4.1.i586
python-sssd-config-1.12.2-3.4.1.i586
sssd-ipa-1.12.2-3.4.1.i586
sssd-1.12.2-3.4.1.i586
sssd-dbus-1.12.2-3.4.1.i586
sssd-krb5-common-1.12.2-3.4.1.i586
sssd-ldap-1.12.2-3.4.1.i586
sssd is confihured for nss, pam, sudo
There is a test sudo rule defined in the ipa server, which applies to
user "doma".  However when the user tries to use sudo the rule does not
work.
doma@nappali:/home/doma> sudo ls
doma's password:
doma is not allowed to run sudo on nappali.  This incident will be reported.
The corresponding log in the sssd_sudo.log is this:
(Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sss_cmd_get_version] (0x0200):
Received client version [1].
(Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sss_cmd_get_version] (0x0200):
Offered version [1].
(Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sss_parse_name_for_domains]
(0x0200): name 'doma' matched without domain, user is doma
(Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sss_parse_name_for_domains]
(0x0200): name 'doma' matched without domain, user is doma
(Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sudosrv_cmd_parse_query_done]
(0x0200): Requesting default options for [doma] from []
(Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sudosrv_get_user] (0x0200):
Requesting info about [doma@szilva]
(Wed Sep  9 21:25:25 2015) [sssd[sudo]]
[sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with
[(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=doma)(sudoUser=#181643)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*))(&(dataExpireTimestamp<=1441826725)))]
(Wed Sep  9 21:25:25 2015) [sssd[sudo]]
[sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with
[(&(objectClass=sudoRule)(|(name=defaults)))]
(Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sss_parse_name_for_domains]
(0x0200): name 'doma' matched without domain, user is doma
(Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sss_parse_name_for_domains]
(0x0200): name 'doma' matched without domain, user is doma
(Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sudosrv_cmd_parse_query_done]
(0x0200): Requesting rules for [doma] from []
(Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sudosrv_get_user] (0x0200):
Requesting info about [doma@szilva]
(Wed Sep  9 21:25:25 2015) [sssd[sudo]]
[sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with
[(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=doma)(sudoUser=#181643)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*))(&(dataExpireTimestamp<=1441826725)))]
(Wed Sep  9 21:25:25 2015) [sssd[sudo]]
[sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with
[(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=doma)(sudoUser=#181643)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*)))]
(Wed Sep  9 21:25:30 2015) [sssd[sudo]] [client_recv] (0x0200): Client
disconnected!
This seems perfectly OK with one exception. The query against the sysdb
does not find the entry. This is strange because the entry is there.
Log in sssd.log:
(Wed Sep  2 08:52:13 2015) [sssd] [sysdb_domain_init_internal] (0x0200):
DB File for szilva: /var/lib/sss/db/cache_szilva.ldb
So we know that the sysdb is /var/lib/sss/db/cache_szilva.ldb
Running the exact same query seen above in the sssd_sudo.log against the
db returns:
ldbsearch -H /var/lib/sss/db/cache_szilva.ldb
"(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=doma)(sudoUser=#181643)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*)))"
asq: Unable to register control with rootdse!
# record 1
dn: name=Doma_ls,cn=sudorules,cn=custom,cn=szilva,cn=sysdb
cn: Doma_ls
dataExpireTimestamp: 1441830262
entryUSN: 20521
name: Doma_ls
objectClass: sudoRule
originalDN: cn=Doma_ls,ou=sudoers,dc=szilva
sudoCommand: ls
sudoHost: nappali.szilva
sudoRunAsGroup: ALL
sudoRunAsUser: ALL
sudoUser: doma
distinguishedName: name=Doma_ls,cn=sudorules,cn=custom,cn=szilva,cn=sysdb
# returned 1 records
# 1 entries
# 0 referrals
This confirms that the entry is indeed there in the db. Why is it found
with ldbsearch and why does sssd_sudo not find it?
I am pretty much stuck with this one. Anyone has an idea?



Hi,
this is strange. Can you provide the logs with debug level set to 0x3ff0 
please? Can you also send it as an attachment? Thanks!


--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Sudo entry not found by sssd in the cache db

[Pavel Březina]

On 09/11/2015 02:40 PM, Molnár Domokos wrote:

Full log attached.
"Molnár Domokos"  írta:


    "Pavel Březina"  írta:

On 09/09/2015 09:31 PM, Molnár Domokos wrote:
 > I have a working IPA server and a working client config on an 
OpenSuse
 > 13.2 with the following versions:
 > nappali:~ # rpm -qa |grep sssd
 > sssd-tools-1.12.2-3.4.1.i586
 > sssd-krb5-1.12.2-3.4.1.i586
 > python-sssd-config-1.12.2-3.4.1.i586
 > sssd-ipa-1.12.2-3.4.1.i586
 > sssd-1.12.2-3.4.1.i586
 > sssd-dbus-1.12.2-3.4.1.i586
 > sssd-krb5-common-1.12.2-3.4.1.i586
 > sssd-ldap-1.12.2-3.4.1.i586
 > sssd is confihured for nss, pam, sudo
 > There is a test sudo rule defined in the ipa server, which applies to
 > user "doma".  However when the user tries to use sudo the rule does 
not
 > work.
 > doma@nappali:/home/doma> sudo ls
 > doma's password:
 > doma is not allowed to run sudo on nappali.  This incident will be 
reported.
 > The corresponding log in the sssd_sudo.log is this:
 > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sss_cmd_get_version] 
(0x0200):
 > Received client version [1].
 > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sss_cmd_get_version] 
(0x0200):
 > Offered version [1].
 > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sss_parse_name_for_domains]
 > (0x0200): name 'doma' matched without domain, user is doma
 > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sss_parse_name_for_domains]
 > (0x0200): name 'doma' matched without domain, user is doma
 > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] 
[sudosrv_cmd_parse_query_done]
 > (0x0200): Requesting default options for [doma] from []
 > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sudosrv_get_user] (0x0200):
 > Requesting info about [doma@szilva]
 > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
 > [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with
 > 
[(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=doma)(sudoUser=#181643)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*))(&(dataExpireTimestamp<=1441826725)))]
 > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
 > [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with
 > [(&(objectClass=sudoRule)(|(name=defaults)))]
 > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sss_parse_name_for_domains]
 > (0x0200): name 'doma' matched without domain, user is doma
 > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sss_parse_name_for_domains]
 > (0x0200): name 'doma' matched without domain, user is doma
 > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] 
[sudosrv_cmd_parse_query_done]
 > (0x0200): Requesting rules for [doma] from []
 > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sudosrv_get_user] (0x0200):
 > Requesting info about [doma@szilva]
 > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
 > [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with
 > 
[(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=doma)(sudoUser=#181643)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*))(&(dataExpireTimestamp<=1441826725)))]
 > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
 > [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with
 > 
[(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=doma)(sudoUser=#181643)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*)))]
 > (Wed Sep  9 21:25:30 2015) [sssd[sudo]] [client_recv] (0x0200): 
Client
 > disconnected!
 > This seems perfectly OK with one exception. The query against the 
sysdb
 > does not find the entry. This is strange because the entry is there.
 > Log in sssd.log:
 > (Wed Sep  2 08:52:13 2015) [sssd] [sysdb_domain_init_internal] 
(0x0200):
 > DB File for szilva: /var/lib/sss/db/cache_szilva.ldb
 > So we know that the sysdb is /var/lib/sss/db/cache_szilva.ldb
 > Running the exact same query seen above in the sssd_sudo.log against 
the
 > db returns:
 > ldbsearch -H /var/lib/sss/db/cache_szilva.ldb
 > 
"(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=doma)(sudoUser=#181643)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*)))"
 > asq: Unable to register control with rootdse!
 > # record 1
 > dn: name=Doma_ls,cn=sudorules,cn=custo

Re: [Freeipa-users] sudo options/sss_cache

[Pavel Březina]

On 09/25/2015 10:06 AM, Jakub Hrozek wrote:

On Thu, Sep 24, 2015 at 03:39:48PM +0200, Christoph Kaminski wrote:

Hi

I have 3 problems/questions with ipa and sudo...

1. How to make a GLOBAL sudo rule with all the options what I want to
have? (e.g. !authenticate). I have tried to make a sudo rule for all users
on all hosts whom all users but without command and it doesnt work... Do I
need to set it for each rule separately?


Pavel (CC) would know this better, in native sudo there is a global
entry but I keep forgetting what it is in IPA..


Hi, please, create a rule named "defaults".

I see this question is returning frequently. I think it should be 
supported directly by user interface.






2. How can I with sss_cache invalidate sudo rules? Do I need ever to kill
all files inside /var/lib/sssd/db? I dont see an option in sss_cache for
this :/


sss_cache can't do that because at the moment the sudo rule updates are
kinda complex. See man sssd-sudo for all the different refreshes. You
can either cycle sssd by sending it USR1 and then USR2 or tune the cache
refreshes.



3. How long is the time where sssd invalidates the sudo rules and make a
new look into ipa? Can I set this time?


See above.



--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] sudo options/sss_cache

[Pavel Březina]

On 09/25/2015 01:12 PM, Jakub Hrozek wrote:

On Fri, Sep 25, 2015 at 11:48:27AM +0200, Pavel Březina wrote:

On 09/25/2015 10:06 AM, Jakub Hrozek wrote:

On Thu, Sep 24, 2015 at 03:39:48PM +0200, Christoph Kaminski wrote:

Hi

I have 3 problems/questions with ipa and sudo...

1. How to make a GLOBAL sudo rule with all the options what I want to
have? (e.g. !authenticate). I have tried to make a sudo rule for all users
on all hosts whom all users but without command and it doesnt work... Do I
need to set it for each rule separately?


Pavel (CC) would know this better, in native sudo there is a global
entry but I keep forgetting what it is in IPA..


Hi, please, create a rule named "defaults".

I see this question is returning frequently. I think it should be supported
directly by user interface.


+1 care to file a ticket?

..and a good candidate for the troubleshooting guide in the works :-)



Hi, I filed a ticket:
https://fedorahosted.org/freeipa/ticket/5332

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Sudo entry not found by sssd in the cache db

[Pavel Březina]

On 09/15/2015 09:10 AM, Molnár Domokos wrote:


"Molnár Domokos"  írta:

On 09/14/2015 03:08 PM, Pavel Březina wrote:

On 09/11/2015 02:40 PM, Molnár Domokos wrote:

Full log attached.
"Molnár Domokos"  írta:


    "Pavel Březina"  írta:

On 09/09/2015 09:31 PM, Molnár Domokos wrote:
 > I have a working IPA server and a working client
config on an OpenSuse
 > 13.2 with the following versions:
 > nappali:~ # rpm -qa |grep sssd
 > sssd-tools-1.12.2-3.4.1.i586
 > sssd-krb5-1.12.2-3.4.1.i586
 > python-sssd-config-1.12.2-3.4.1.i586
 > sssd-ipa-1.12.2-3.4.1.i586
 > sssd-1.12.2-3.4.1.i586
 > sssd-dbus-1.12.2-3.4.1.i586
 > sssd-krb5-common-1.12.2-3.4.1.i586
 > sssd-ldap-1.12.2-3.4.1.i586
 > sssd is confihured for nss, pam, sudo
 > There is a test sudo rule defined in the ipa server,
which applies to
 > user "doma".  However when the user tries to use sudo
the rule does not
 > work.
 > doma@nappali:/home/doma> sudo ls
 > doma's password:
 > doma is not allowed to run sudo on nappali.  This
incident will be reported.
 > The corresponding log in the sssd_sudo.log is this:
 > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
[sss_cmd_get_version] (0x0200):
 > Received client version [1].
 > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
[sss_cmd_get_version] (0x0200):
 > Offered version [1].
 > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
[sss_parse_name_for_domains]
 > (0x0200): name 'doma' matched without domain, user is doma
 > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
[sss_parse_name_for_domains]
 > (0x0200): name 'doma' matched without domain, user is doma
 > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
[sudosrv_cmd_parse_query_done]
 > (0x0200): Requesting default options for [doma] from
[]
 > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
[sudosrv_get_user] (0x0200):
 > Requesting info about [doma@szilva]
 > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
 > [sudosrv_get_sudorules_query_cache] (0x0200):
Searching sysdb with
 >

[(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=doma)(sudoUser=#181643)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*))(&(dataExpireTimestamp<=1441826725)))]
 > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
 > [sudosrv_get_sudorules_query_cache] (0x0200):
Searching sysdb with
 > [(&(objectClass=sudoRule)(|(name=defaults)))]
 > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
[sss_parse_name_for_domains]
 > (0x0200): name 'doma' matched without domain, user is doma
 > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
[sss_parse_name_for_domains]
 > (0x0200): name 'doma' matched without domain, user is doma
 > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
[sudosrv_cmd_parse_query_done]
 > (0x0200): Requesting rules for [doma] from []
 > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
[sudosrv_get_user] (0x0200):
 > Requesting info about [doma@szilva]
 > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
 > [sudosrv_get_sudorules_query_cache] (0x0200):
Searching sysdb with
 >

[(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=doma)(sudoUser=#181643)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*))(&(dataExpireTimestamp<=1441826725)))]
 > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
 > [sudosrv_get_sudorules_query_cache] (0x0200):
Searching sysdb with
 >

[(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=doma)(sudoUser=#181643)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*)))]
 > (Wed Sep  9 21:25:30 2015) [sssd[sudo]] [client_recv]
(0x0200): Client
 > disconnected!
 > This seems perfectly OK with one exception. The query
against the sysdb
 > does not find the entry. This is strange because the
entry is there.
 > Log in sssd.log:
 > (Wed Sep  2 08:52:13 2015) [sssd]
[sysdb_domain_init_internal] (0x0200):
 > DB File for szilva: /var/lib/sss/db/cache_szilva.ldb
 > So we know that the sysdb is
/var/lib/sss/db/cache_szilva.ldb

Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo

[Pavel Březina]

On 09/21/2015 10:42 PM, Andy Thompson wrote:

On Mon, Sep 21, 2015 at 07:39:01PM +, Andy Thompson wrote:

-Original Message-
From: Jakub Hrozek [mailto:jhro...@redhat.com]
Sent: Monday, September 21, 2015 3:29 PM
To: Andy Thompson 
Cc: freeipa-users@redhat.com; pbrez...@redhat.com
Subject: Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo

On Mon, Sep 21, 2015 at 02:22:54PM +, Andy Thompson wrote:


On Thu, Sep 17, 2015 at 11:42:54AM +, Andy Thompson wrote:

I've narrowed it down a bit doing some testing.  The sudo
rules work when

I remove the user group restriction from them.  My sudo rules
all have my ad groups in the rule


   Rule name: ad_linux_admins
   Enabled: TRUE
   Host category: all
   Command category: all
   RunAs User category: all
   RunAs Group category: all
   User Groups: ad_linux_admins  <- if I remove this then the
rule gets

applied

Nice catch. Is the group visible after you login and run id?

What is the exact IPA server version?


Ok I also figured out if I rename my AD groups to match my IPA
groups then

the sudo rules are applied.


I tested a couple things though, if I put a rule in the local
sudoers file on a server running sssd 1.11

%@   "sudo commands"

That rule was not applied.  If I remove the  then the
rule got

applied.


On a server running sssd 1.12 that rule works, but does not work
if I

remove the .  And none of the IPA sudo rules work.  So
something changed with the domain suffix between versions it would
appear.


They key to making the IPA sudo rules work in 1.12 is to remove
the

default_domain_suffix setting in the sssd.conf, but that's not an
option in my environment.


So all the moving parts together, it appears that having AD groups
with a different name than the IPA groups in conjunction with the
default_domain_suffix setting breaks things right now in 1.12.
Appears since I renamed the ad group to match then the rule
without a domain suffix will get matched now


Hello Andy,

I'm sorry for the constant delays, but I was busy with some
trust-related fixes lately.

Did you have a chance to confirm that just swapping sssd /on the
client/ while keeping the same version on the server fixes the issue for

you?


Pavel (CC), can you help me out here, please? I have the setup ready
on my machine, so tomorrow we can take a look and experiment (I can
give you access to my environment via tmate maybe..), but I wasn't
able to reproduce the issue locally yet.


It's fine I understand the backlog.

I was not able to backrev the sssd due to dependency issues.  I tried

downgrading all the dependencies and got in a loop and stopped trying.  Are
there any tricks you can think of to downgrade the sssd cleanly?


-andy



What failures are you getting? I normally just download all \*sss\* packages
and then downgrade with rpm -U --oldpackage.



I'm just trying to use yum.  If I yum downgrade sssd I get a ton of deps.  If 
include all the deps it lists

yum downgrade sssd sssd-proxy sssd-ipa sssd-common-pac sssd-krb5 
sssd-krb5-common sssd-ldap sssd-ad libipa_hbac libipa_hbac-python 
python-sssdconfig

I get multilib errors with libsss_idmap.

Looks like my local repo doesn't have libsss_idmap 1.11 available.  Let me look 
into that and see what repo it sits in and see if I can figure out why it's not 
pulling in.

-andy



Hi, since none of us is able to reproduce this in house, can you give us 
more precise steps how to reproduce and more information? What I have in 
mind at this moment is:


1) How is membership defined? I suspect it goes as AD-USER -> AD-GROUP 
-> IPA->GROUP, right? What types of groups are used?


2) sssd.conf might also turn out to be useful

3) Remove SSSD and sudo logs, reproduce and send us all the logs please 
with the commands to reproduce. Not just snippets.


Do you have any test machine we can ssh to?

Thank you!

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo

[Pavel Březina]

On 09/30/2015 09:04 PM, Andy Thompson wrote:

On Wed, Sep 30, 2015 at 12:17:22PM +, Andy Thompson wrote:

On 09/21/2015 10:42 PM, Andy Thompson wrote:

On Mon, Sep 21, 2015 at 07:39:01PM +, Andy Thompson wrote:

-Original Message-
From: Jakub Hrozek [mailto:jhro...@redhat.com]
Sent: Monday, September 21, 2015 3:29 PM
To: Andy Thompson 
Cc: freeipa-users@redhat.com; pbrez...@redhat.com
Subject: Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo

On Mon, Sep 21, 2015 at 02:22:54PM +, Andy Thompson wrote:


On Thu, Sep 17, 2015 at 11:42:54AM +, Andy Thompson

wrote:

I've narrowed it down a bit doing some testing.  The sudo
rules work when

I remove the user group restriction from them.  My sudo rules
all have my ad groups in the rule


Rule name: ad_linux_admins
Enabled: TRUE
Host category: all
Command category: all
RunAs User category: all
RunAs Group category: all
User Groups: ad_linux_admins  <- if I remove this then
the rule gets

applied

Nice catch. Is the group visible after you login and run id?

What is the exact IPA server version?


Ok I also figured out if I rename my AD groups to match my IPA
groups then

the sudo rules are applied.


I tested a couple things though, if I put a rule in the local
sudoers file on a server running sssd 1.11

%@   "sudo commands"

That rule was not applied.  If I remove the  then
the rule got

applied.


On a server running sssd 1.12 that rule works, but does not
work if I

remove the .  And none of the IPA sudo rules work.
So something changed with the domain suffix between versions it
would appear.


They key to making the IPA sudo rules work in 1.12 is to
remove the

default_domain_suffix setting in the sssd.conf, but that's not
an option in my environment.


So all the moving parts together, it appears that having AD
groups with a different name than the IPA groups in
conjunction with the default_domain_suffix setting breaks things

right now in 1.12.

Appears since I renamed the ad group to match then the rule
without a domain suffix will get matched now


Hello Andy,

I'm sorry for the constant delays, but I was busy with some
trust-related fixes lately.

Did you have a chance to confirm that just swapping sssd /on
the client/ while keeping the same version on the server fixes
the issue for

you?


Pavel (CC), can you help me out here, please? I have the setup
ready on my machine, so tomorrow we can take a look and
experiment (I can give you access to my environment via tmate
maybe..), but I wasn't able to reproduce the issue locally yet.


It's fine I understand the backlog.

I was not able to backrev the sssd due to dependency issues.  I
tried

downgrading all the dependencies and got in a loop and stopped
trying.  Are there any tricks you can think of to downgrade the
sssd

cleanly?


-andy



What failures are you getting? I normally just download all
\*sss\* packages and then downgrade with rpm -U --oldpackage.



I'm just trying to use yum.  If I yum downgrade sssd I get a ton
of deps.  If include all the deps it lists

yum downgrade sssd sssd-proxy sssd-ipa sssd-common-pac sssd-krb5
sssd-krb5-common sssd-ldap sssd-ad libipa_hbac libipa_hbac-python
python-sssdconfig

I get multilib errors with libsss_idmap.

Looks like my local repo doesn't have libsss_idmap 1.11 available.
Let me

look into that and see what repo it sits in and see if I can figure
out why it's not pulling in.


-andy



Hi, since none of us is able to reproduce this in house, can you
give us more precise steps how to reproduce and more information?
What I have in mind at this moment is:

1) How is membership defined? I suspect it goes as AD-USER ->
AD-GROUP
-> IPA->GROUP, right? What types of groups are used?



I have AD user->AD group->external IPA group->IPA group


2) sssd.conf might also turn out to be useful

3) Remove SSSD and sudo logs, reproduce and send us all the logs
please with the commands to reproduce. Not just snippets.



I can gather this up and get it over to you.

Actually I just realized I have two other environments and this is working

without issue in those environments.  I haven't done a full sudo rollout in
those environments yet so I didn't think to check those, but the admins rule
is working correctly and I haven't renamed any ad groups to match my IPA
groups.


Could it be something in a sudo rule or something in AD that's interfering

with this working correctly?

I would first try to find the difference in the environment. Are sssd versions
the same on the clients and servers? Are sudo versions the same?

...etc.

Pavel has a sudo troubleshooting guide in the works, maybe it would help..


All updates are controlled from the same repo so versions are all the same 
between the environments, that's why I'm wondering if something in AD could 
cause this.  Can't imagine what it would be though.  Groups are all mapped in 
the same way.
>Sudo is setup the same and works fine it was just the AD group name 
being 

Re: [Freeipa-users] can't get sudo to work.

[Pavel Březina]

On 08/23/2016 11:26 AM, Tony Brian Albers wrote:

Thanks Jakub,

I've attached a file with the output from looking in the log files
mentioned in the link you gave me.

I'm not sure exactly what is wrong, I don't know how to interpret
messages like: name 'tba-sadm' matched without domain, user is tba
-sadm   (is that good or bad?)

Any advice is appreciated.


Hi,
unfortunately the attached file is empty. Can you resend it? You can 
send it to me privately if you want. I will need both sssd and sudo logs 
(both described in the troubleshooting page).


Thank you.



/tony


--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] can't get sudo to work.

[Pavel Březina]

On 08/23/2016 01:55 PM, Tony Brian Albers wrote:

Here you are:


[root ~]# ldapsearch -Y GSSAPI -b $dc
'(ou=*)' -s onelevel



# profile, $domain
dn: ou=profile,$dc
objectClass: top
objectClass: organizationalUnit
ou: profiles
ou: profile

# search result
search: 4
result: 0 Success

# numResponses: 2
# numEntries: 1



Sudo rules are not downloaded by SSSD because ou=sudoers is missing on 
the IPA server, or it may have incorrect ACL. Does someone from IPA team 
know why?


--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] sudo rules question on ubuntu 16.0.1

[Pavel Březina]

On 08/25/2016 08:01 PM, Jeff Goddard wrote:

I'm still hoping someone can offer additional help. I see in the apt
term.log these errors when downloading the freeipa-client package. Could
this be the problem?


Hi,
I'm sorry, I somehow overlooked this thread. Can you provide output of 
ipa sudorule-show please?


Thank you.


--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] sudo rules question on ubuntu 16.0.1

[Pavel Březina]

On 08/26/2016 02:15 PM, Jeff Goddard wrote:

Pavel,

I appreciate that you're busy and thank you for taking time to look at
this. Here is the output:

[root@id-management-1 ~]# ipa sudorule-show
Rule name: all
   Rule name: All
   Description: Full sudo access for Developer group in office environment
   Enabled: TRUE
   Command category: all
   RunAs User category: all
   RunAs Group category: all
   User Groups: developers
   Host Groups: office
[root@id-management-1 ~]#


Hi,
unfortunately sudo 1.8.16 introduced a bug in sssd plugin. 1.8.16 
contains a new option called netgroup_tuple, which tells whether a full 
netgroup tuply is check or only the host/user part in host/user check. 
However, the patch didn't make the sssd plugin to obey this option and 
it always check both hostname and username.


It is fixed in 1.8.17 by this patch:
https://www.sudo.ws/repos/sudo/rev/2eab4070dcf7

Please, report bug against Ubuntu sudo to backport this patch or rebase 
sudo.


--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Help with sudo permission for a command

[Pavel Březina]

On 08/30/2016 05:08 PM, Ryan Whalen wrote:

Hi All,

Im having an issue getting a command to run properly, and the issue
seems to be with Freeipa sudo permissions. Specifically 'sudo su -
app_user -c ""' prompts for a password when run.

However if I 'sudo su - app_user' and then run the '' as
app_user, it works fine.

example:
```
$ ssh r...@production-server.pp
Last login: Mon Aug 29 21:36:14 2016 from 10.20.3.15
ryan$ sudo su - app_user -c "df"
[sudo] password for ryan:
^C
ryan$ sudo su - app_user
app_user$ df
Filesystem   1K-blocks Used Available Use% Mounted on
/dev/sda3 14845784  6667296   7417708  48% /
tmpfs  14742280   1474228   0% /dev/shm
/dev/sda1   48765281221380831  18% /boot
10.51.0.34:/srv/nfs/app
  287687168 69111040 218576128  25% /var/app
10.51.0.54:/srv/nfs/ipa
   16377088  3728640  11809792  24% /home/ipa
ap_user$
```

I have a sudo rule that allows `/bin/su - app_user` and `/bin/su -
app_user -c` but I cant get the `-c` to work in a single command. I also
tried giving sudo permission to `/bin/bash` in case the `-c` needed it
to create a new shell for some reason, but it didn't work.

Does anyone have any thoughts on what permissions I might be missing to
allow the user to run `sudo su - app_user -c `?

Thanks,
Ryan




Try to allow /bin/su - app_user -c '*'

If I understand you correctly, you want to allow user to run any command 
as app_user. You can do it also by creating a rule that allows to run 
any command and run it as app_user.


--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] sudo !requiretty !authenticate

[Pavel Březina]

On 01/05/2015 07:32 PM, Craig White wrote:

Hi - reply at bottom

-Original Message-
From: Martin Kosek [mailto:mko...@redhat.com]
Sent: Monday, January 05, 2015 4:33 AM
To: Craig White; freeipa-users@redhat.com; Pavel Brezina
Subject: Re: [Freeipa-users] sudo !requiretty !authenticate

On 01/02/2015 07:47 PM, Craig White wrote:

Subject pretty much says it all.

Starting to play around with rundeck and was thinking it would be nice if I 
could create a user that had the ability to sudo, without password, a public 
key and the ability to run commands.

But the use of 'sudo' gets me an error that says it requires a tty to run sudo. 
So I tried by creating a sudo rule that has options '!requiretty !authenticate' 
but it still complains that I need a tty. Is there a FreeIPA method that I am 
lacking?

Craig White
System Administrator
O 623-201-8179   M 602-377-9752

[cid:image001.png@01CF86FE.42D51630]

SkyTouch Technology 4225 E. Windrose Dr. Phoenix, AZ 85032


CCing Pavel to advise.

 From top of my head - did you try clearing SSSD cache before calling the sudo 
command again? Did you enter the options in the FreeIPA SUDO entry correctly?
Maybe the problem is that each option should be filed as a separate attribute 
value and you entered it as one combined attribute value.

Martin

Thanks Martin

Unclear how to 'clear SSSD cache' so I restarted SSSD service on the testing 
box but it didn't help.

$ ipa sudorule-show --all
Rule name: rundeck
   dn: ipaUniqueID=XX,cn=sudorules,cn=sudo,dc=stt,dc=local
   Rule name: rundeck
   Enabled: TRUE
   Host category: all
   Command category: all
   RunAs User category: all
   Users: rundeck
   Sudo Option: !requiretty, !authenticate
   ipauniqueid: XX
   objectclass: ipaassociation, ipasudorule

At this point, !requiretty and !authenticate are separate options but I have 
previously tried them as a bundle together but the results are the same...

sudo: sorry, you must have a tty to run sudo   :-(

(client system)
# rpm -qa | egrep 'ipa|sssd'
sssd-ldap-1.11.6-30.el6.x86_64
libipa_hbac-1.11.6-30.el6.x86_64
python-sssdconfig-1.11.6-30.el6.noarch
sssd-ipa-1.11.6-30.el6.x86_64
sssd-client-1.11.6-30.el6.x86_64
sssd-common-1.11.6-30.el6.x86_64
sssd-ad-1.11.6-30.el6.x86_64
sssd-1.11.6-30.el6.x86_64
python-iniparse-0.3.1-2.1.el6.noarch
libipa_hbac-python-1.11.6-30.el6.x86_64
sssd-krb5-common-1.11.6-30.el6.x86_64
sssd-krb5-1.11.6-30.el6.x86_64
sssd-common-pac-1.11.6-30.el6.x86_64
ipa-python-3.0.0-42.el6.x86_64
sssd-proxy-1.11.6-30.el6.x86_64
ipa-client-3.0.0-42.el6.x86_64


Hi,
just to be sure that the problem is indeed in options - the rule without 
any sudoOption and with only one of them does work, right?


Can you send us sudo debug log? You can enable debug log by putting the 
following line in /etc/sudo.conf:


Debug sudo /var/log/sudo.log all@debug


--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project

Re: [Freeipa-users] sudo !requiretty !authenticate

[Pavel Březina]

On 01/07/2015 06:32 PM, Craig White wrote:

Still struggling with this...

$ sudo /sbin/service pe-puppet restart
  [sudo] password for rundeck:
Stopping puppet:   [  OK  ]
Starting puppet:   [  OK  ]

So it asks for the password even though, via FreeIPA it isn't required...

$ sudo -l
Matching Defaults entries for rundeck 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

User rundeck may run the following commands on this host:
 (root) ALL
 (ALL) NOPASSWD: ALL


Hi,
thank you, I was just going to ask you for sudo -l. I believe that the 
problem is that (root) ALL rule takes precedence. Or to be more precise, 
the first rule that matches is always applied, unless sudoOrder 
attribute is present (but that is not supported by IPA, is it?).


Try removing the rule (root) ALL, restarting sssd and wait until the 
cache is refreshed and see if that works.




And all of the info is provided previously/below that should be needed 
including the sudo debug log in yesterday's email if anyone has the time to 
help me figure out what is going wrong here.

-Original Message-
From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Craig White
Sent: Tuesday, January 06, 2015 10:17 AM
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] sudo !requiretty !authenticate

-Original Message-
From: Lukas Slebodnik [mailto:lsleb...@redhat.com]
Sent: Tuesday, January 06, 2015 3:11 AM
To: Craig White
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] sudo !requiretty !authenticate

On (06/01/15 10:21), Pavel Březina wrote:

On 01/05/2015 07:32 PM, Craig White wrote:

Hi - reply at bottom

-Original Message-
From: Martin Kosek [mailto:mko...@redhat.com]
Sent: Monday, January 05, 2015 4:33 AM
To: Craig White; freeipa-users@redhat.com; Pavel Brezina
Subject: Re: [Freeipa-users] sudo !requiretty !authenticate

On 01/02/2015 07:47 PM, Craig White wrote:

Subject pretty much says it all.

Starting to play around with rundeck and was thinking it would be nice if I 
could create a user that had the ability to sudo, without password, a public 
key and the ability to run commands.

But the use of 'sudo' gets me an error that says it requires a tty to run sudo. 
So I tried by creating a sudo rule that has options '!requiretty !authenticate' 
but it still complains that I need a tty. Is there a FreeIPA method that I am 
lacking?

Craig White
System Administrator
O 623-201-8179   M 602-377-9752

[cid:image001.png@01CF86FE.42D51630]

SkyTouch Technology 4225 E. Windrose Dr. Phoenix, AZ 85032


CCing Pavel to advise.

 From top of my head - did you try clearing SSSD cache before calling the sudo 
command again? Did you enter the options in the FreeIPA SUDO entry correctly?
Maybe the problem is that each option should be filed as a separate attribute 
value and you entered it as one combined attribute value.

Martin

Thanks Martin

Unclear how to 'clear SSSD cache' so I restarted SSSD service on the testing 
box but it didn't help.

$ ipa sudorule-show --all
Rule name: rundeck
   dn: ipaUniqueID=XX,cn=sudorules,cn=sudo,dc=stt,dc=local
   Rule name: rundeck
   Enabled: TRUE
   Host category: all
   Command category: all
   RunAs User category: all
   Users: rundeck
   Sudo Option: !requiretty, !authenticate
   ipauniqueid: XX
   objectclass: ipaassociation, ipasudorule

At this point, !requiretty and !authenticate are separate options but I have 
previously tried them as a bundle together but the results are the same...

sudo: sorry, you must have a tty to run sudo   :-(

(client system)
# rpm -qa | egrep 'ipa|sssd'
sssd-ldap-1.11.6-30.el6.x86_64
libipa_hbac-1.11.6-30.el6.x86_64
python-sssdconfig-1.11.6-30.el6.noarch
sssd-ipa-1.11.6-30.el6.x86_64
sssd-client-1.11.6-30.el6.x86_64
sssd-common-1.11.6-30.el6.x86_64
sssd-ad-1.11.6-30.el6.x86_64
sssd-1.11.6-30.el6.x86_64
python-iniparse-0.3.1-2.1.el6.noarch
libipa_hbac-python-1.11.6-30.el6.x86_64
sssd-krb5-common-1.11.6-30.el6.x86_64
sssd-krb5-1.11.6-30.el6.x86_64
sssd-common-pac-1.11.6-30.el6.x86_64
ipa-python-3.0.0-42.el6.x86_64
sssd-proxy-1.11.6-30.el6.x86_64
ipa-client-3.0.0-42.el6.x86_64


Hi,
just to be sure that the problem is indeed in options - the rule
without any sudoOption and with only one of them does work, right?

Can you send us sudo debug log? You can enable debug log b

Re: [Freeipa-users] sudo !requiretty !authenticate

[Pavel Březina]

On 01/08/2015 07:54 PM, Craig White wrote:

-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com]
Sent: Thursday, January 08, 2015 9:33 AM
To: Craig White; Martin Kosek; Pavel Březina; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] sudo !requiretty !authenticate

Craig White wrote:

-Original Message-
From: freeipa-users-boun...@redhat.com
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Martin Kosek
Sent: Thursday, January 08, 2015 5:30 AM
To: Pavel Březina; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] sudo !requiretty !authenticate

On 01/08/2015 10:45 AM, Pavel Březina wrote:

On 01/07/2015 06:32 PM, Craig White wrote:

Still struggling with this...

$ sudo /sbin/service pe-puppet restart
   [sudo] password for rundeck:
Stopping puppet:   [  OK  ]
Starting puppet:   [  OK  ]

So it asks for the password even though, via FreeIPA it isn't required...

$ sudo -l
Matching Defaults entries for rundeck 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

User rundeck may run the following commands on this host:
  (root) ALL
  (ALL) NOPASSWD: ALL


Hi,
thank you, I was just going to ask you for sudo -l. I believe that
the problem is that (root) ALL rule takes precedence. Or to be more
precise, the first rule that matches is always applied, unless
sudoOrder attribute is present (but that is not supported by IPA, is it?).


JFTR, sudoOrder *is* supported in FreeIPA, since FreeIPA 3.3.4 (upstream ticket 
https://fedorahosted.org/freeipa/ticket/4107).


I see said the blind man. Obviously the root/ALL rule is part and parcel of 
RHEL distribution of sudo package.

$ rpm -q ipa-server
ipa-server-3.0.0-42.el6.x86_64

$ cat sudoOrder.ldif
dn: cn=suoders,cn=Schema Compatibility,cn=plugins,cn=config
changetype: modify
add: schema-compat-entry-attribute
schema-compat-entry-attribute: sudoOrder=%{sudoOrder}

$ ldapmodify -x -h `hostname` -D "cn=Directory Manager" -W -f
sudoOrder.ldif Enter LDAP Password:
modifying entry "cn=suoders,cn=Schema Compatibility,cn=plugins,cn=config"
ldap_modify: No such object (32)
 additional info: Range Check error

bummer   :-(


You have a typo, suoders instead of sudoers.

You might also experiment with order in the sudoers entry in 
/etc/nsswitch.conf, try sss files. Or if you don't intend on storing any rules 
in files, perhaps drop it.

Thanks for catching my typo - my bad.

This is interesting. First tried 'sss files' and then just 'sss' for sudoers in 
nsswitch.conf but no go.

$ sudo -l

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

 #1) Respect the privacy of others.
 #2) Think before you type.
 #3) With great power comes great responsibility.

[sudo] password for rundeck:
Matching Defaults entries for rundeck on this host:
 !requiretty

User rundeck may run the following commands on this host:
 (root) ALL
 (ALL) NOPASSWD: ALL

So !authenticate doesn't show up even though I have had the rule in ipa for 2 
days now.


Hi,
!authenticate does show up. It shows up as word NOPASSWD, in the rule list.


$ ipa sudorule-show rundeck
   Rule name: rundeck
   Enabled: TRUE
   Host category: all
   Command category: all
   RunAs User category: all
   RunAs Group category: all
   Users: rundeck
   Sudo Option: !authenticate

That '(root) ALL' rule doesn't come from /etc/sudoers as I thought because 
nsswitch.conf presently only uses sss for sudoers. I still don't see where it 
actually comes from though...



It may come from all of the rules below expect rundeck. What groups is 
the user you are running sudo as member of? If he is member of one of 
the groups puppet, sysadmin, sysengineer that the rules below containing 
sudoCommand: ALL and not containing sudoRunAsUser: ALL shows up as 
(root): ALL.




$ ldapsearch -x -h `hostname` -D "cn=Directory Manager" -W -b 
ou=sudoers,dc=stt,dc=local
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# sudoers, stt.local
dn: ou=sudoers,dc=stt,dc=local
objectClass: extensibleObject
ou: sudoers

# defaults, sudoers, stt.local
dn: cn=defaults,ou=sudoers,dc=stt,dc=local
objectClass: sudoRole
sudoOption: !requiretty
cn: defaults

# rundeck, sudoers, stt.lo

Re: [Freeipa-users] Issue IPA: AD Users and IPA Users when using SSS/LDAP with SUDO

[Pavel Březina]

On 04/24/2013 07:20 PM, Aly Khimji wrote:

(Wed Apr 24 13:07:35 2013) [sssd[be[nix.corpnonprd..com]]] 
[be_pam_handler_callback] (0x0100): Backend returned: (0, 0, ) [Success]
(Wed Apr 24 13:07:35 2013) [sssd[be[nix.corpnonprd..com]]] 
[sss_selinux_extract_user] (0x0040): sysdb_search_user_by_name failed.
(Wed Apr 24 13:07:35 2013) [sssd[be[nix.corpnonprd..com]]] 
[ipa_selinux_handler] (0x0040): Cannot create op context
(Wed Apr 24 13:07:35 2013) [sssd[be[nix.corpnonprd..com]]] 
[be_pam_handler_callback] (0x0100): Backend returned: (3, 4, ) [Internal 
Error (System error)]


Hi,
this looks like a selinux problem to me. What happens when you set
selinux to permissive?

Also does this problem occur only with sudo, or other services are 
affected too (id, authentication, ssh)?


Can you please perform following commands? It will remove cache and logs 
so do it in a safe non-production environment.


As root:
# service stop sssd
# rm -f /var/lib/sss/db/* /var/lib/sss/mc/* /var/log/sssd/*
# service sssd start

As normal user:
$ su ad-user@trusted-domain
$ sudo -l
$ exit

And send us the sanitized logs (all of them).

Thank you.






___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Issue IPA: AD Users and IPA Users when using SSS/LDAP with SUDO

[Pavel Březina]

On 04/29/2013 08:31 PM, Aly Khimji wrote:

Hey Pavel/Guys,

Do you see anything in the new logs that might help?

I saw this bug https://bugzilla.redhat.com/show_bug.cgi?id=871160 that
reports this issue exactly.
However its reported as fixed but I am still having the same issue. I am
building out a new test environment and I am also deploying a FC18
client which seems to have newer sssd/libsss_sudo packages that i
suppose haven't made it up stream yet

Currently installed on my client

libsss_sudo-1.9.2-82.7.el6_4.x86_64
sssd-client-1.9.2-82.7.el6_4.x86_64
libsss_idmap-1.9.2-82.7.el6_4.x86_64
libsss_autofs-1.9.2-82.el6.x86_64
sssd-1.9.2-82.7.el6_4.x86_64

I've increased the logging to 10, just incase it helps. here it the
sss_sudo log for a login, then sudo attempt


Thx

Aly


Hi,
I'm sorry for such a late answer. The logs says, that in the time of 
using sudo, the user akhimji is not present in the cache, which should 
not happen if you managed to log in. I will try to reproduce the issue 
first thing tomorrow and let you know.


___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Issue IPA: AD Users and IPA Users when using SSS/LDAP with SUDO

[Pavel Březina]

On 05/03/2013 12:42 PM, Aly Khimji wrote:

Hey Pavel/guys

Any luck recreating the problem?


Hi,
sorry for the delay. I can confirm that sudo does not work with users 
from trusted domain anymore. I created a ticket:


https://fedorahosted.org/sssd/ticket/1912

Patch for 1.9 branch is on sssd-devel list.


Thx for the help

Aly


Thanks Pavel,

Very much appreciated

Aly


On Tue, Apr 30, 2013 at 1:41 PM, Pavel Brezina mailto:pbrez...@redhat.com>> wrote:



- Original Message -
 > From: "Pavel Březina" mailto:pbrez...@redhat.com>>
 > To: "Aly Khimji" mailto:aly.khi...@gmail.com>>
 > Cc: freeipa-users@redhat.com <mailto:freeipa-users@redhat.com>
 > Sent: Monday, April 29, 2013 9:11:25 PM
 > Subject: Re: [Freeipa-users] Issue IPA: AD Users and IPA Users
when using SSS/LDAP with SUDO
 >
 > On 04/29/2013 08:31 PM, Aly Khimji wrote:
 > > Hey Pavel/Guys,
 > >
 > > Do you see anything in the new logs that might help?
 > >
 > > I saw this bug
https://bugzilla.redhat.com/show_bug.cgi?id=871160 that
 > > reports this issue exactly.
 > > However its reported as fixed but I am still having the same
issue. I am
 > > building out a new test environment and I am also deploying a FC18
 > > client which seems to have newer sssd/libsss_sudo packages that i
 > > suppose haven't made it up stream yet
 > >
 > > Currently installed on my client
 > >
 > > libsss_sudo-1.9.2-82.7.el6_4.x86_64
 > > sssd-client-1.9.2-82.7.el6_4.x86_64
 > > libsss_idmap-1.9.2-82.7.el6_4.x86_64
 > > libsss_autofs-1.9.2-82.el6.x86_64
 > > sssd-1.9.2-82.7.el6_4.x86_64
 > >
 > > I've increased the logging to 10, just incase it helps. here it the
 > > sss_sudo log for a login, then sudo attempt
 > >
 > >
 > > Thx
 > >
 > > Aly
 >
 > Hi,
 > I'm sorry for such a late answer. The logs says, that in the time of
 > using sudo, the user akhimji is not present in the cache, which
should
 > not happen if you managed to log in. I will try to reproduce the
issue
 > first thing tomorrow and let you know.

Hi,
I'm sorry, I had some technical diffucilties and didn't manage to
get to it today. Will try it as soon as possible.




___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Sudo Commands and groups confusion

[Pavel Březina]

On 06/12/2013 02:37 PM, Jakub Hrozek wrote:

On Wed, Jun 12, 2013 at 11:22:35AM +0200, Matt . wrote:

Hi,

The package as you described is installed, the configlines are set as you
show it.

This is what I see in auth.log, my sssd_sudo does not show a thing:

Jun 12 11:19:16 server sudo: pam_unix(sudo:auth): authentication failure;
logname=USERNAME uid=86666 euid=0 tty=/dev/pts/0 ruser=USERNAME rhost=
user=USERNAME
Jun 12 11:19:16 server sudo: pam_sss(sudo:auth): User info message: Your
password will expire in 89 day(s).
Jun 12 11:19:16 server sudo: pam_sss(sudo:auth): authentication success;
logname=USERNAME uid=86666 euid=0 tty=/dev/pts/0 ruser=USERNAME rhost=
user=USERNAME
Jun 12 11:19:16 server sudo: USERNAME : user NOT in sudoers ; TTY=pts/0 ;
PWD=/ ; USER=root ; COMMAND=/bin/su


Pavel, I know you were debugging this problem on IRC, was there any
conclusion?



No. I'm waiting for our lab to come back online so I can try to 
reproduce it.



Jun 12 11:19:16 server sudo: unable to execute /usr/sbin/sendmail: No such
file or directory

I really cannot figure out what to check more.


2013/6/12 Alexander Bokovoy 


On Wed, 12 Jun 2013, Matt . wrote:


Hi,

A lot of people seem to have problem with Sudo and FreeIPA.

How to enable sudo is described here:

http://www.freeipa.org/images/**7/77/Freeipa30_SSSD_SUDO_**
Integration.pdf

The problem we are facing, also discussed on IRC is that there is looked
in
the local sudoers file of the client if the loggedin user may sudo. Of
course the username is not known there.


Not sure what exactly is your problem? Could you please rephrase and
show it with logs again?

If you are using SSSD's sudo integration against IPA server, then here
is what you need to get it working on Fedora 18/19 and RHEL 6.4:

1. install libsss_sudo package

2. Add/change following line to /etc/nsswitch.conf

sudoers: files sss

3. Make sure your /etc/sssd/sssd.conf looks like this example:
http://abbra.fedorapeople.org/**.paste/sssd.conf.example
4. Restart sssd

These are the only actions I needed to get sudo working for IPA users on
Fedora 19 and RHEL 6.4.

Please note thatsudoers: files sss
gives you chance to have local users configured in local sudoers. If you
don't want them to be able to use sudo, just change the line in
/etc/nsswitch.conf to
sudoers: sss


--
/ Alexander Bokovoy




___
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 Commands and groups confusion

[Pavel Březina]

On 06/12/2013 02:51 PM, Pavel Březina wrote:

On 06/12/2013 02:37 PM, Jakub Hrozek wrote:

On Wed, Jun 12, 2013 at 11:22:35AM +0200, Matt . wrote:

Hi,

The package as you described is installed, the configlines are set as
you
show it.

This is what I see in auth.log, my sssd_sudo does not show a thing:

Jun 12 11:19:16 server sudo: pam_unix(sudo:auth): authentication
failure;
logname=USERNAME uid=86666 euid=0 tty=/dev/pts/0 ruser=USERNAME
rhost=
user=USERNAME
Jun 12 11:19:16 server sudo: pam_sss(sudo:auth): User info message: Your
password will expire in 89 day(s).
Jun 12 11:19:16 server sudo: pam_sss(sudo:auth): authentication success;
logname=USERNAME uid=86666 euid=0 tty=/dev/pts/0 ruser=USERNAME
rhost=
user=USERNAME
Jun 12 11:19:16 server sudo: USERNAME : user NOT in sudoers ;
TTY=pts/0 ;
PWD=/ ; USER=root ; COMMAND=/bin/su


Pavel, I know you were debugging this problem on IRC, was there any
conclusion?



No. I'm waiting for our lab to come back online so I can try to
reproduce it.


I followed the deployment guide and everything works fine. If you still 
have problem, please start over and follow:

[1] for sudo-ldap-ipa
[2] for sudo-sssd-ipa

Check list:
- NIS domain has to be set to IPA domain

- hostname must be set to fqdn

- sudo-ldap configuration file on RHEL systems is located at
  # sudo -V | grep ldap.conf
  ldap.conf path: /etc/sudo-ldap.conf

- nsswitch must contain sudoers: ldap or sudoers: sss
  # cat /etc/nsswitch.conf  | grep sudoers
  sudoers: files ldap


[1] 
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html#example-configuring-sudo


[2] http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf




Jun 12 11:19:16 server sudo: unable to execute /usr/sbin/sendmail: No
such
file or directory

I really cannot figure out what to check more.


2013/6/12 Alexander Bokovoy 


On Wed, 12 Jun 2013, Matt . wrote:


Hi,

A lot of people seem to have problem with Sudo and FreeIPA.

How to enable sudo is described here:

http://www.freeipa.org/images/**7/77/Freeipa30_SSSD_SUDO_**
Integration.pdf<http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf>


The problem we are facing, also discussed on IRC is that there is
looked
in
the local sudoers file of the client if the loggedin user may sudo. Of
course the username is not known there.


Not sure what exactly is your problem? Could you please rephrase and
show it with logs again?

If you are using SSSD's sudo integration against IPA server, then here
is what you need to get it working on Fedora 18/19 and RHEL 6.4:

1. install libsss_sudo package

2. Add/change following line to /etc/nsswitch.conf

sudoers: files sss

3. Make sure your /etc/sssd/sssd.conf looks like this example:
http://abbra.fedorapeople.org/**.paste/sssd.conf.example<http://abbra.fedorapeople.org/.paste/sssd.conf.example>

4. Restart sssd

These are the only actions I needed to get sudo working for IPA
users on
Fedora 19 and RHEL 6.4.

Please note thatsudoers: files sss
gives you chance to have local users configured in local sudoers. If
you
don't want them to be able to use sudo, just change the line in
/etc/nsswitch.conf to
sudoers: sss


--
/ Alexander Bokovoy




___
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


___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] sudo rules user and host group bugs?

[Pavel Březina]

On 07/17/2013 06:39 PM, Tovey, Mark wrote:


 Okay, I get it (pardon my obtuseness).

 host1-> getent netgroup hgroup1
 hgroup1   (host1.my_domain.com, -, my_domain.com)

 So netgroups are working.  The host group is defined in IPA and getent is 
able to access that information.
 Thanks,
 -Mark


Hi,
can you also paste the output of following commands please?

$ nisdomainname
$ rpm -q sudo

Thanks,
Pavel.





Mark Tovey - UNIX Engineer | Service Strategy & Design
UTi | 400 SW Sixth Ave, Suite 1100 | Portland | Oregon | 97204 | USA
mto...@go2uti.com | O / C +1 503 953-1389


-Original Message-
From: Jakub Hrozek [mailto:jhro...@redhat.com]
Sent: Wednesday, July 17, 2013 8:58 AM
To: Tovey, Mark
Cc: d...@redhat.com; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] sudo rules user and host group bugs?

On Wed, Jul 17, 2013 at 03:01:58PM +, Tovey, Mark wrote:


 We have sssd-1.5.1-58.el5 and ipa-client-2.1.3-5.el5_9.2 installed.


OK, these are recent enough to support netgroups and the compat tree should be 
configured automatically.


Those came out of the 'latest' repository.  We do not have any netgroups 
defined (there is no /etc/netgroup file), so getent does not return anything.


Every hostgroup is automatically translated into a netgroup on the server side. You said 
you have some host groups present, so does "getent netgroup  
return any netgroup data?


 Thanks,
 -Mark






Mark Tovey - UNIX Engineer | Service Strategy & Design UTi | 400 SW
Sixth Ave, Suite 1100 | Portland | Oregon | 97204 | USA
mto...@go2uti.com | O / C +1 503 953-1389


-Original Message-
From: Jakub Hrozek [mailto:jhro...@redhat.com]
Sent: Wednesday, July 17, 2013 1:32 AM
To: Tovey, Mark
Cc: d...@redhat.com; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] sudo rules user and host group bugs?

On Tue, Jul 16, 2013 at 09:13:00PM +, Tovey, Mark wrote:



 We are using sssd. The sssd.conf file is mostly unchanged from how it was 
installed by the ipa-client-install script:


Hi Mark,

you said your client is OEL *5.5* ? The SSSD first appeared in RHEL (and by 
extension OEL) in 5.6. Are you running the version from EPEL? I'm not sure if 
netgroups were even supported in that old version..

What is the output of "rpm -q sssd" and "rpm -q ipa-client" ?

Does getent netgroup  work?



[sssd]
config_file_version = 2
services = nss, pam

domains = my_domain.com
[nss]

[pam]

  [domain/my_domain.com]
cache_credentials = True
krb5_store_password_if_offline = True ipa_domain = my_domain.com
id_provider = ipa auth_provider = ipa access_provider = ipa
chpass_provider = ipa ipa_server = _srv_, ipa_server.my_domain.com
ldap_tls_cacert = /etc/ipa/ca.crt debug_level = 6


 And the nsswitch.conf file:

passwd: files sss
shadow: files sss
group:  files sss

hosts:  files dns

bootparams: nisplus [NOTFOUND=return] files

ethers: files
netmasks:   files
networks:   files
protocols:  files
rpc:files
services:   files

netgroup:   files sss

publickey:  nisplus

automount:  files ldap
aliases:files

sudoers:files ldap

 Thanks,
 -Mark




Mark Tovey - UNIX Engineer | Service Strategy & Design UTi | 400 SW
Sixth Ave, Suite 1100 | Portland | Oregon | 97204 | USA
mto...@go2uti.com | O / C +1 503 953-1389 | Skype: mark.tovey2


-Original Message-
From: freeipa-users-boun...@redhat.com
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Dmitri Pal
Sent: Tuesday, July 16, 2013 12:51 PM
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] sudo rules user and host group bugs?

On 07/16/2013 02:11 PM, Tovey, Mark wrote:

 My environment consists of OEL 5.5 clients with ipa-client-2.1.3 and the 
server is OEL 6.4 with ipa-server-3.0.0.  We chose these because we were able 
to find RPM packages for them.  We would prefer to go with the latest versions, 
but we did not want to spend the time building installation packages just yet.  
Again, we are just evaluating at this point.  So far, so good, except for this 
one point.
 The doman name, host name, and nsswitch.conf files are all properly configured.  But I do not have any 
netgroups defined (the getent command doesn't return anything and there is no /etc/netgroup file).  After you 
asked about that, I started looking into the documentation on netgroups.  The IPA documentation for sudo 
states that "Identity Management creates two groups, a visible host group and a shadow netgroup. sudo 
itself only supports NIS-style netgroups for group formats."  But when I look in the Netgroups area, I 
do not see any netgroups defined.  I used Apache Directory Studio to look around the Directory Server, and I 
can see "cn=hgroup1,cn=ng,cn=alt,dc=my_domain,dc=com", along with 

Re: [Freeipa-users] sudo rules user and host group bugs?

[Pavel Březina]

Hi,
hostname command outputs "host1.my_domain.com", right? This version of 
sudo is very old, I'll check the code and eventually consult with sudo 
maintainer.


On 07/19/2013 06:49 PM, Tovey, Mark wrote:


 Does anyone have any other suggestions for this or need any additional 
information?
 Thanks,
 -Mark



Mark Tovey - UNIX Engineer | Service Strategy & Design
UTi | 400 SW Sixth Ave, Suite 1100 | Portland | Oregon | 97204 | USA
mto...@go2uti.com | O / C +1 503 953-1389

-Original Message-
From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Tovey, Mark
Sent: Thursday, July 18, 2013 11:06 AM
To: Pavel Březina; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] sudo rules user and host group bugs?



host1-> nisdomainname
my_domain.com

host1-> rpm -q sudo
sudo-1.7.2p1-6.el5_5

 Thanks,
 -Mark



Mark Tovey - UNIX Engineer | Service Strategy & Design UTi | 400 SW Sixth Ave, 
Suite 1100 | Portland | Oregon | 97204 | USA mto...@go2uti.com | O / C +1 503 
953-1389

-Original Message-
From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Pavel Brezina
Sent: Thursday, July 18, 2013 2:03 AM
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] sudo rules user and host group bugs?

On 07/17/2013 06:39 PM, Tovey, Mark wrote:


  Okay, I get it (pardon my obtuseness).

  host1-> getent netgroup hgroup1
  hgroup1   (host1.my_domain.com, -, my_domain.com)

  So netgroups are working.  The host group is defined in IPA and getent is 
able to access that information.
  Thanks,
  -Mark


Hi,
can you also paste the output of following commands please?

$ nisdomainname
$ rpm -q sudo

Thanks,
Pavel.





Mark Tovey - UNIX Engineer | Service Strategy & Design UTi | 400 SW
Sixth Ave, Suite 1100 | Portland | Oregon | 97204 | USA
mto...@go2uti.com | O / C +1 503 953-1389


-Original Message-
From: Jakub Hrozek [mailto:jhro...@redhat.com]
Sent: Wednesday, July 17, 2013 8:58 AM
To: Tovey, Mark
Cc: d...@redhat.com; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] sudo rules user and host group bugs?

On Wed, Jul 17, 2013 at 03:01:58PM +, Tovey, Mark wrote:


  We have sssd-1.5.1-58.el5 and ipa-client-2.1.3-5.el5_9.2 installed.


OK, these are recent enough to support netgroups and the compat tree should be 
configured automatically.


Those came out of the 'latest' repository.  We do not have any netgroups 
defined (there is no /etc/netgroup file), so getent does not return anything.


Every hostgroup is automatically translated into a netgroup on the server side. You said 
you have some host groups present, so does "getent netgroup  
return any netgroup data?


  Thanks,
  -Mark






Mark Tovey - UNIX Engineer | Service Strategy & Design UTi | 400 SW
Sixth Ave, Suite 1100 | Portland | Oregon | 97204 | USA
mto...@go2uti.com | O / C +1 503 953-1389


-Original Message-
From: Jakub Hrozek [mailto:jhro...@redhat.com]
Sent: Wednesday, July 17, 2013 1:32 AM
To: Tovey, Mark
Cc: d...@redhat.com; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] sudo rules user and host group bugs?

On Tue, Jul 16, 2013 at 09:13:00PM +, Tovey, Mark wrote:



  We are using sssd. The sssd.conf file is mostly unchanged from how it was 
installed by the ipa-client-install script:


Hi Mark,

you said your client is OEL *5.5* ? The SSSD first appeared in RHEL (and by 
extension OEL) in 5.6. Are you running the version from EPEL? I'm not sure if 
netgroups were even supported in that old version..

What is the output of "rpm -q sssd" and "rpm -q ipa-client" ?

Does getent netgroup  work?



[sssd]
config_file_version = 2
services = nss, pam

domains = my_domain.com
[nss]

[pam]

   [domain/my_domain.com]
cache_credentials = True
krb5_store_password_if_offline = True ipa_domain = my_domain.com
id_provider = ipa auth_provider = ipa access_provider = ipa
chpass_provider = ipa ipa_server = _srv_, ipa_server.my_domain.com
ldap_tls_cacert = /etc/ipa/ca.crt debug_level = 6


  And the nsswitch.conf file:

passwd: files sss
shadow: files sss
group:  files sss

hosts:  files dns

bootparams: nisplus [NOTFOUND=return] files

ethers: files
netmasks:   files
networks:   files
protocols:  files
rpc:files
services:   files

netgroup:   files sss

publickey:  nisplus

automount:  files ldap
aliases:files

sudoers:files ldap

  Thanks,
  -Mark




Mark Tovey - UNIX Engineer | Service Strategy & Design UTi | 400 SW

Re: [Freeipa-users] sudo rules user and host group bugs?

[Pavel Březina]

Hi,
the code says it should work. I don't see any problem with the 
configuration. Since the netgroup is resolved correctly I do not think 
the problem resides in IPA.


Can you rerun sudo with -D 9? That may yield some more information. 
Also, you can try asking on sudo-users list. Todd (sudo author) may have 
some more ideas.


On 07/19/2013 09:47 PM, Tovey, Mark wrote:


 That is correct:

host1-> hostname
host1.my_domain.com

 I was beginning to suspect that it is in sudo.  I checked the 
documentation for that version of sudo and it does include support for 
netgroups.  Perhaps I need something extra in the sudoers file, or an 
additional option.
 Thanks,
 -Mark


Mark Tovey - UNIX Engineer | Service Strategy & Design
UTi | 400 SW Sixth Ave, Suite 1100 | Portland | Oregon | 97204 | USA
mto...@go2uti.com | O / C +1 503 953-1389


-Original Message-
From: Pavel Březina [mailto:pbrez...@redhat.com]
Sent: Friday, July 19, 2013 11:01 AM
To: Tovey, Mark
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] sudo rules user and host group bugs?

Hi,
hostname command outputs "host1.my_domain.com", right? This version of sudo is 
very old, I'll check the code and eventually consult with sudo maintainer.

On 07/19/2013 06:49 PM, Tovey, Mark wrote:


  Does anyone have any other suggestions for this or need any additional 
information?
  Thanks,
  -Mark



Mark Tovey - UNIX Engineer | Service Strategy & Design UTi | 400 SW
Sixth Ave, Suite 1100 | Portland | Oregon | 97204 | USA
mto...@go2uti.com | O / C +1 503 953-1389

-Original Message-
From: freeipa-users-boun...@redhat.com
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Tovey, Mark
Sent: Thursday, July 18, 2013 11:06 AM
To: Pavel Březina; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] sudo rules user and host group bugs?



host1-> nisdomainname
my_domain.com

host1-> rpm -q sudo
sudo-1.7.2p1-6.el5_5

  Thanks,
  -Mark



Mark Tovey - UNIX Engineer | Service Strategy & Design UTi | 400 SW
Sixth Ave, Suite 1100 | Portland | Oregon | 97204 | USA
mto...@go2uti.com | O / C +1 503 953-1389

-Original Message-
From: freeipa-users-boun...@redhat.com
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Pavel Brezina
Sent: Thursday, July 18, 2013 2:03 AM
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] sudo rules user and host group bugs?

On 07/17/2013 06:39 PM, Tovey, Mark wrote:


   Okay, I get it (pardon my obtuseness).

   host1-> getent netgroup hgroup1
   hgroup1   (host1.my_domain.com, -, my_domain.com)

   So netgroups are working.  The host group is defined in IPA and getent 
is able to access that information.
   Thanks,
   -Mark


Hi,
can you also paste the output of following commands please?

$ nisdomainname
$ rpm -q sudo

Thanks,
Pavel.





Mark Tovey - UNIX Engineer | Service Strategy & Design UTi | 400 SW
Sixth Ave, Suite 1100 | Portland | Oregon | 97204 | USA
mto...@go2uti.com | O / C +1 503 953-1389


-Original Message-
From: Jakub Hrozek [mailto:jhro...@redhat.com]
Sent: Wednesday, July 17, 2013 8:58 AM
To: Tovey, Mark
Cc: d...@redhat.com; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] sudo rules user and host group bugs?

On Wed, Jul 17, 2013 at 03:01:58PM +, Tovey, Mark wrote:


   We have sssd-1.5.1-58.el5 and ipa-client-2.1.3-5.el5_9.2 installed.


OK, these are recent enough to support netgroups and the compat tree should be 
configured automatically.


Those came out of the 'latest' repository.  We do not have any netgroups 
defined (there is no /etc/netgroup file), so getent does not return anything.


Every hostgroup is automatically translated into a netgroup on the server side. You said 
you have some host groups present, so does "getent netgroup  
return any netgroup data?


   Thanks,
   -Mark






Mark Tovey - UNIX Engineer | Service Strategy & Design UTi | 400 SW
Sixth Ave, Suite 1100 | Portland | Oregon | 97204 | USA
mto...@go2uti.com | O / C +1 503 953-1389


-Original Message-
From: Jakub Hrozek [mailto:jhro...@redhat.com]
Sent: Wednesday, July 17, 2013 1:32 AM
To: Tovey, Mark
Cc: d...@redhat.com; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] sudo rules user and host group bugs?

On Tue, Jul 16, 2013 at 09:13:00PM +, Tovey, Mark wrote:



   We are using sssd. The sssd.conf file is mostly unchanged from how it 
was installed by the ipa-client-install script:


Hi Mark,

you said your client is OEL *5.5* ? The SSSD first appeared in RHEL (and by 
extension OEL) in 5.6

Re: [Freeipa-users] freeipa and sudo

[Pavel Březina]

On 09/08/2013 01:35 AM, Dmitri Pal wrote:

On 09/07/2013 02:11 PM, Christian Horn wrote:

On Sat, Sep 07, 2013 at 12:06:37PM -0500, Dean Hunter wrote:

Are [1] and[2] still the current and best sources of information for
configuring sudo for use with the current release of FreeIPA on Fedora
19?

1.
http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/sudo.html
2.
http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf

There is also the Identity_Management_Guide as part of the RHEL
product documentation:
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html

This and the pdf above are the latest word in this area.


Hi,
those documents describes configuration for SSSD 1.9. Although it is 
still valid, we have simplified configuration for IPA provider in 1.10.


The most up to date document for your version of SSSD is always man 
sssd-sudo.


___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] freeipa and sudo

[Pavel Březina]

On 09/08/2013 11:11 PM, Jakub Hrozek wrote:

On Sun, Sep 08, 2013 at 03:42:16PM -0500, Dean Hunter wrote:

On Sat, 2013-09-07 at 19:35 -0400, Dmitri Pal wrote:


On 09/07/2013 02:11 PM, Christian Horn wrote:

On Sat, Sep 07, 2013 at 12:06:37PM -0500, Dean Hunter wrote:

Are [1] and[2] still the current and best sources of information for
configuring sudo for use with the current release of FreeIPA on Fedora
19?

1.
http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/sudo.html
2.
http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf

There is also the Identity_Management_Guide as part of the RHEL
product documentation:
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html

This and the pdf above are the latest word in this area.


Christian

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users





Some sudo rules are causing:

   [dean@desktop2 ~]$ sudo id
   sudo: internal error, tried to erealloc3(0)


This is a known bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1000389

I think the sudo rules are just missing the sudoHost attribute.



, but others do not.  In the trial and error process of determining
which rule specifications are causing the error, I have been restarting
the virtual machine I am using as the sudo client between tests.  Is
there a better way to clear the SSSD cache between trials to make sure I
am testing the most recent rule change?


Unfortunately right now the only way is to rm the sssd cache which would
also remove any cached credentials.


You don't necessarily have to remove the cache. If you just restart SSSD 
the rules will be refreshed in approximately 15 seconds.


 I thought there was an RFE open to

track the enhancement to make sss_cache invalidate and refresh sudo
rules, but I can't find it now in the SSSD trac, so I filed another one:
https://fedorahosted.org/sssd/ticket/2081

Worst case, we mark it as a duplicate.

___
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] freeipa and sudo

[Pavel Březina]

On 09/09/2013 12:26 AM, Dean Hunter wrote:

On Sun, 2013-09-08 at 23:11 +0200, Jakub Hrozek wrote:

On Sun, Sep 08, 2013 at 03:42:16PM -0500, Dean Hunter wrote:
> On Sat, 2013-09-07 at 19:35 -0400, Dmitri Pal wrote:
>
> > On 09/07/2013 02:11 PM, Christian Horn wrote:
> > > On Sat, Sep 07, 2013 at 12:06:37PM -0500, Dean Hunter wrote:
> > >> Are [1] and[2] still the current and best sources of information for
> > >> configuring sudo for use with the current release of FreeIPA on Fedora
> > >> 19?
> > >>
> > >> 1.
> > >>http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/sudo.html
> > >> 2.
> > >>http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf
> > > There is also the Identity_Management_Guide as part of the RHEL
> > > product documentation:
> > 
>https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html
> > This and the pdf above are the latest word in this area.
> >
> > > Christian
> > >
> > > ___
> > > Freeipa-users mailing list
> > >Freeipa-users@redhat.com  
> > >https://www.redhat.com/mailman/listinfo/freeipa-users
> >
> >
>
> Some sudo rules are causing:
>
>   [dean@desktop2 ~]$ sudo id
>   sudo: internal error, tried to erealloc3(0)

This is a known bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1000389

I think the sudo rules are just missing the sudoHost attribute.

>
> , but others do not.  In the trial and error process of determining
> which rule specifications are causing the error, I have been restarting
> the virtual machine I am using as the sudo client between tests.  Is
> there a better way to clear the SSSD cache between trials to make sure I
> am testing the most recent rule change?

Unfortunately right now the only way is to rm the sssd cache which would
also remove any cached credentials. I thought there was an RFE open to
track the enhancement to make sss_cache invalidate and refresh sudo
rules, but I can't find it now in the SSSD trac, so I filed another one:
https://fedorahosted.org/sssd/ticket/2081

Worst case, we mark it as a duplicate.

___
Freeipa-users mailing list
Freeipa-users@redhat.com  
https://www.redhat.com/mailman/listinfo/freeipa-users


I saw bug report 1000389, but I could not understand it or whether it
applied to me.

I discovered that sudo rules for which I specified a host group caused
the error.  Rules with a host category of "all" instead of the host
group did not cause the error.  Is this what 1000389 says?

   ipa sudorule-addserver-admins  --desc "Server Administrators"
   ipa sudorule-modserver-admins  --cmdcat all
# ipa sudorule-add-host   server-admins  --hostgroups servers
   ipa sudorule-modserver-admins  --hostcat all
   ipa sudorule-add-option server-admins  --sudooption '!authenticate'
   ipa sudorule-add-runasuser  server-admins  --users root
   ipa sudorule-add-runasgroup server-admins  --groups root
   ipa sudorule-add-user   server-admins  --groups server-admins


Does the machine where sudo prints this error belongs to the hostgroup 
'servers'? If the answer is *no* then you are hitting 1000389.



This problem exists with the latest updates on both Fedora 18 and Fedora 19.

I also discovered that libsss_sudo.so is missing from  Fedora 18
installations.


It needs to be installed separately by installing libsss_sudo package.

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] freeipa and sudo

[Pavel Březina]

On 09/09/2013 07:32 PM, Dean Hunter wrote:


On Mon, 2013-09-09 at 11:23 +0200, Pavel Březina wrote:

On 09/08/2013 01:35 AM, Dmitri Pal wrote:

On 09/07/2013 02:11 PM, Christian Horn wrote:

On Sat, Sep 07, 2013 at 12:06:37PM -0500, Dean Hunter wrote:

Are [1] and[2] still the current and best sources of
information for configuring sudo for use with the current
release of FreeIPA on Fedora 19?

1.
http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/sudo.html





2.

http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf





There is also the Identity_Management_Guide as part of the RHEL

product documentation:
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html





This and the pdf above are the latest word in this area.


Hi, those documents describes configuration for SSSD 1.9. Although
it is still valid, we have simplified configuration for IPA
provider in 1.10.

The most up to date document for your version of SSSD is always
man sssd-sudo.

___ Freeipa-users
mailing list Freeipa-users@redhat.com
<mailto:Freeipa-users@redhat.com>
https://www.redhat.com/mailman/listinfo/freeipa-users


Thank you.  Please verify that I have correctly understood your note.
 Your slides from 12-20-2012 applied to SSSD 1.9 and included a
reference to the manual pages, which I now understand, as well as
this example configuration:

sudo_provider = ldap ldap_uri = ldap://ipa.example.com
ldap_sudo_search_base = ou=sudoers,dc=example,dc=com ldap_sasl_mech =
GSSAPI ldap_sasl_authid = host/hostname.example.com ldap_sasl_realm =
EXAMPLE.COM krb5_server = ipa.example.com

I have used this configuration with good results.  However, reading
"man sssd-sudo" from sssd-1.9.5-2.fc18.x86_64 I find this paragraph:

When the SSSD is configured to use the IPA provider, the sudo
provider is automatically enabled. The sudo search base is configured
to use the compat tree (ou=sudoers,$DC).


I forgot that the configuration was simplified also in 1.9. You can just
stick with contents of sssd-sudo. I.e. you only need to put sudo to
"services" (there's an RFE to do it automatically by ipa-client-install)
and "sudoers: files sss" to /etc/nsswitch.conf


May I suggest that you change "IPA provider" to "IPA as the ID
provider"?  There are a number of providers identified in sssd.conf
and most of them are configured to use IPA.


This is a valid point, thanks.



Testing shows that the only change now required to sssd.conf is the
addition of sudo to the services list in the sssd section [sssd]:

services = autofs, nss, pam, ssh, sudo

Add to this the one line change in nsswitch.conf

sudoers:files sss

and I am done.


Correct.

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] freeipa and sudo

[Pavel Březina]

On 09/09/2013 05:53 PM, Dean Hunter wrote:

On Mon, 2013-09-09 at 11:35 +0200, Pavel Březina wrote:

On 09/09/2013 12:26 AM, Dean Hunter wrote:
> On Sun, 2013-09-08 at 23:11 +0200, Jakub Hrozek wrote:
>> On Sun, Sep 08, 2013 at 03:42:16PM -0500, Dean Hunter wrote:
>> > On Sat, 2013-09-07 at 19:35 -0400, Dmitri Pal wrote:
>> >
>> > > On 09/07/2013 02:11 PM, Christian Horn wrote:
>> > > > On Sat, Sep 07, 2013 at 12:06:37PM -0500, Dean Hunter wrote:
>> > > >> Are [1] and[2] still the current and best sources of information for
>> > > >> configuring sudo for use with the current release of FreeIPA on Fedora
>> > > >> 19?
>> > > >>
>> > > >> 1.
>> > > 
>>http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/sudo.html
>> > > >> 2.
>> > > >>http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf
>> > > > There is also the Identity_Management_Guide as part of the RHEL
>> > > > product documentation:
>> > > 
>https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html
>> > > This and the pdf above are the latest word in this area.
>> > >
>> > > > Christian
>> > > >
>> > > > ___
>> > > > Freeipa-users mailing list
>> > > >Freeipa-users@redhat.com  <mailto:Freeipa-users@redhat.com>   
<mailto:Freeipa-users@redhat.com>
>> > > >https://www.redhat.com/mailman/listinfo/freeipa-users
>> > >
>> > >
>> >
>> > Some sudo rules are causing:
>> >
>> >   [dean@desktop2 ~]$ sudo id
>> >   sudo: internal error, tried to erealloc3(0)
>>
>> This is a known bug:
>>https://bugzilla.redhat.com/show_bug.cgi?id=1000389
>>
>> I think the sudo rules are just missing the sudoHost attribute.
>>
>> >
>> > , but others do not.  In the trial and error process of determining
>> > which rule specifications are causing the error, I have been restarting
>> > the virtual machine I am using as the sudo client between tests.  Is
>> > there a better way to clear the SSSD cache between trials to make sure I
>> > am testing the most recent rule change?
>>
>> Unfortunately right now the only way is to rm the sssd cache which would
>> also remove any cached credentials. I thought there was an RFE open to
>> track the enhancement to make sss_cache invalidate and refresh sudo
>> rules, but I can't find it now in the SSSD trac, so I filed another one:
>>https://fedorahosted.org/sssd/ticket/2081
>>
>> Worst case, we mark it as a duplicate.
>>
>> ___
>> Freeipa-users mailing list
>>Freeipa-users@redhat.com  <mailto:Freeipa-users@redhat.com>   
<mailto:Freeipa-users@redhat.com>
>>https://www.redhat.com/mailman/listinfo/freeipa-users
>
> I saw bug report 1000389, but I could not understand it or whether it
> applied to me.
>
> I discovered that sudo rules for which I specified a host group caused
> the error.  Rules with a host category of "all" instead of the host
> group did not cause the error.  Is this what 1000389 says?
>
>ipa sudorule-addserver-admins  --desc "Server Administrators"
>ipa sudorule-modserver-admins  --cmdcat all
> # ipa sudorule-add-host   server-admins  --hostgroups servers
>ipa sudorule-modserver-admins  --hostcat all
>ipa sudorule-add-option server-admins  --sudooption '!authenticate'
>ipa sudorule-add-runasuser  server-admins  --users root
>ipa sudorule-add-runasgroup server-admins  --groups root
>ipa sudorule-add-user   server-admins  --groups server-admins

Does the machine where sudo prints this error belongs to the hostgroup
'servers'? If the answer is *no* then you are hitting 1000389.


Yes, the virtual machine where the sudo internal error occurs is a
member of the hostgroup.  So I guess this is a new error and should be
reported?


FYI Dean reported https://bugzilla.redhat.com/show_bug.cgi?id=1006611

I still think it is the same bug as 1000389, however with slightly 
different back trace. I'll follow up in BZ.





> This problem exists with the latest updates on both Fedora 18 and Fedora 19.
>
> I also discovered that libsss_sudo.so is missing from  Fedora 18
> installations.

It needs to be installed separately by installing libsss_sudo package.


Yes, I did find the package and installed it.


___
Freeipa-users mailing list
Freeipa-users@redhat.com  <mailto: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



___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] freeipa and sudo

[Pavel Březina]

On 09/11/2013 11:21 AM, Pavel Březina wrote:

On 09/09/2013 07:32 PM, Dean Hunter wrote:


On Mon, 2013-09-09 at 11:23 +0200, Pavel Březina wrote:

On 09/08/2013 01:35 AM, Dmitri Pal wrote:

On 09/07/2013 02:11 PM, Christian Horn wrote:

On Sat, Sep 07, 2013 at 12:06:37PM -0500, Dean Hunter wrote:

Are [1] and[2] still the current and best sources of
information for configuring sudo for use with the current
release of FreeIPA on Fedora 19?

1.
http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/sudo.html






2.

http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf






There is also the Identity_Management_Guide as part of the RHEL

product documentation:
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html






This and the pdf above are the latest word in this area.


Hi, those documents describes configuration for SSSD 1.9. Although
it is still valid, we have simplified configuration for IPA
provider in 1.10.

The most up to date document for your version of SSSD is always
man sssd-sudo.

___ Freeipa-users
mailing list Freeipa-users@redhat.com
<mailto:Freeipa-users@redhat.com>
https://www.redhat.com/mailman/listinfo/freeipa-users


Thank you.  Please verify that I have correctly understood your note.
 Your slides from 12-20-2012 applied to SSSD 1.9 and included a
reference to the manual pages, which I now understand, as well as
this example configuration:

sudo_provider = ldap ldap_uri = ldap://ipa.example.com
ldap_sudo_search_base = ou=sudoers,dc=example,dc=com ldap_sasl_mech =
GSSAPI ldap_sasl_authid = host/hostname.example.com ldap_sasl_realm =
EXAMPLE.COM krb5_server = ipa.example.com

I have used this configuration with good results.  However, reading
"man sssd-sudo" from sssd-1.9.5-2.fc18.x86_64 I find this paragraph:

When the SSSD is configured to use the IPA provider, the sudo
provider is automatically enabled. The sudo search base is configured
to use the compat tree (ou=sudoers,$DC).


I forgot that the configuration was simplified also in 1.9. You can just
stick with contents of sssd-sudo. I.e. you only need to put sudo to
"services" (there's an RFE to do it automatically by ipa-client-install)
and "sudoers: files sss" to /etc/nsswitch.conf


May I suggest that you change "IPA provider" to "IPA as the ID
provider"?  There are a number of providers identified in sssd.conf
and most of them are configured to use IPA.


This is a valid point, thanks.


https://fedorahosted.org/sssd/ticket/2085





Testing shows that the only change now required to sssd.conf is the
addition of sudo to the services list in the sssd section [sssd]:

services = autofs, nss, pam, ssh, sudo

Add to this the one line change in nsswitch.conf

sudoers:files sss

and I am done.


Correct.

___
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 rule still working after deactivation

[Pavel Březina]

On 11/13/2013 05:40 PM, Jakub Hrozek wrote:

On Wed, Nov 13, 2013 at 05:26:32PM +0100, David Kreuter wrote:

During our evaluation phase we're facing following problem. One particular user 
were granted sudo permission with the help of a sudo rule. The user can 
successfully access the host via SSH and switched to user root by using the 
sudo command, which was enabled for the user with the sudo rule. After that the 
sudo rule was disabled and the user tried to login again and switching to root 
was still possible.

After deleting the SSSD cache files and restarting the service sudo did not 
work anymore, as excepted.

How long does it take until the sudo rules are refreshed in SSSD cache? I know 
that there are three different refresh mechanism (full, smart, rule). Full and 
smart refresh mechanism are performed periodically dependent on the settings in 
SSSD configuration file and rule method should refresh the users's specific 
rules after each login, what apparently was not the case for my test scenario. 
Please correct me if i'm wrong. Of course I can set the interval for smart 
refresh to a minimum of 10 seconds, but this would cause a lot of traffic.

How can I configure SSSD to update the rules during each login of the user?


Hi David,

Pavel Brezina (CC-ed) would know for sure as he wrote the sudo
integration, but I think the trick could be to force the rules refresh
to run more often, as you noted, detecting the removed rules.

I'd suggest to lower the entry_cache_sudo_timeout to make the rules expire
faster which would trigger the rules refresh which, if it detected rules
were removed would trigger the full refresh.


Hi,
this is completely correct answer.


Currently there's no config option that would tie login and rules
refresh update.


And this sounds like a nice RFE :-)


___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Sudo denied on first attempt, allowed on second attempt

[Pavel Březina]

On 02/16/2014 01:19 AM, Steve Dainard wrote:

Just experienced the same issue on Fedora 20:

[sdainard-ad...@miovision.corp@fed20 ~]$ sudo systemctl stop firewalld
[sudo] password for sdainard-ad...@miovision.corp:
sdainard-ad...@miovision.corp is not allowed to run sudo on fed20.  This
incident will be reported.
[sdainard-ad...@miovision.corp@fed20 ~]$ sudo systemctl stop firewalld
[sudo] password for sdainard-ad...@miovision.corp:
[sdainard-ad...@miovision.corp@fed20 ~]$

Sat Feb 15 19:10:30 2014 is the 2nd attempt in the logs (attached).

/var/log/messages:
Feb 15 19:10:31 fed20 systemd: Stopping firewalld - dynamic firewall
daemon...
Feb 15 19:10:31 fed20 systemd: Stopped firewalld - dynamic firewall daemon.



*Steve Dainard *
IT Infrastructure Manager
Miovision  | /Rethink Traffic/

*Blog   | **LinkedIn
  | Twitter
  | Facebook
*

Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener,
ON, Canada | N2C 1L3
This e-mail may contain information that is privileged or confidential.
If you are not the intended recipient, please delete the e-mail and any
attachments and notify us immediately.


On Fri, Feb 14, 2014 at 4:33 PM, Steve Dainard mailto:sdain...@miovision.com>> wrote:

On a Ubuntu 13.10 client after configuring sssd to provide sudo
service I left the client idle for a few hours. On returning, I
unlocked the screensaver and did the following:

sdainard-ad...@miovision.corp@ubu1310:~$ sudo su
[sudo] password for sdainard-ad...@miovision.corp:
sdainard-ad...@miovision.corp is not allowed to run sudo on ubu1310.
  This incident will be reported.
sdainard-ad...@miovision.corp@ubu1310:~$ sudo su
[sudo] password for sdainard-ad...@miovision.corp:
root@ubu1310:/home/miovision.corp/sdainard-admin#

I haven't experienced this on a Fedora 20 or EL client so I'm
guessing this is something specific to Ubuntu.

I've attached the client sssd log if anyone can point me in the
right direction.

Thanks,


*Steve Dainard *
IT Infrastructure Manager
Miovision  | /Rethink Traffic/

*Blog   | **LinkedIn
  | Twitter
  | Facebook
*

Miovision Technologies Inc. | 148 Manitou Drive, Suite 101,
Kitchener, ON, Canada | N2C 1L3
This e-mail may contain information that is privileged or
confidential. If you are not the intended recipient, please delete
the e-mail and any attachments and notify us immediately.


Hi,
provided logs did not reveal anything bad. Can you also attach 
sssd_sudo.log, sssd_nss.log and sssd.conf please? Also what sssd and 
sudo version do you run?


Is this always reproducible or it happens only sporadically?

Thanks.

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Sudo denied on first attempt, allowed on second attempt

[Pavel Březina]

On 02/17/2014 10:29 PM, Steve Dainard wrote:

I can't reproduce consistently on any OS including Fedora 20, but I was
able to trigger the issue on a Ubuntu 13.10 client.

sssd: 1.11.1

sudo: 1.8.6p3-0ubuntu3

I have only just enabled the sudo logging so it should only contain the
events below:

sdainard-ad...@miovision.corp@ubu1310:~$ sudo su
[sudo] password for sdainard-ad...@miovision.corp:
sdainard-ad...@miovision.corp is not allowed to run sudo on ubu1310.
  This incident will be reported.
sdainard-ad...@miovision.corp@ubu1310:~$ sudo su
[sudo] password for sdainard-ad...@miovision.corp:
root@ubu1310:/home/miovision.corp/sdainard-admin#

Files attached outside of list.


Hi,
thank you for the logs. Can you also send me output of command "id 
sdainard-admin" (also check if group membership is correct) and 
definition of the sudo rule please?


Also you may want to fix the following (unrelated) warning:
Deprecation warning: The option ipa_dyndns_update is deprecated and 
should not be used in favor of dyndns_update


___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Sudo denied on first attempt, allowed on second attempt

[Pavel Březina]

On 02/18/2014 10:32 PM, Steve Dainard wrote:

Hi Pavel,

Very interesting, my IPA group membership in ad_admins isn't shown by
that command on first run (new login)

sdainard-ad...@miovision.corp@ubu1310:~$ id sdainard-admin
uid=799002462(sdainard-ad...@miovision.corp)
gid=799002462(sdainard-ad...@miovision.corp)
groups=799002462(sdainard-ad...@miovision.corp),799001380(accounting-share-acc...@miovision.corp),799001417(protected-share-acc...@miovision.corp),799000519(enterprise
adm...@miovision.corp),799001416(hr-share-acc...@miovision.corp),799000512(domain
adm...@miovision.corp),799000513(domain
us...@miovision.corp),799002464(it -
adm...@miovision.corp),799002469(kloperat...@miovision.corp),799002468(kladm...@miovision.corp)

sdainard-ad...@miovision.corp@ubu1310:~$ sudo su
[sudo] password for sdainard-ad...@miovision.corp:
sdainard-ad...@miovision.corp is not allowed to run sudo on ubu1310.
  This incident will be reported.

But after attempting the sudo command my groups do contain the IPA
groups admins,ad_admins:

sdainard-ad...@miovision.corp@ubu1310:~$ id sdainard-admin
uid=799002462(sdainard-ad...@miovision.corp)
gid=799002462(sdainard-ad...@miovision.corp)
groups=799002462(sdainard-ad...@miovision.corp),799001380(accounting-share-acc...@miovision.corp),799001417(protected-share-acc...@miovision.corp),799000519(enterprise
adm...@miovision.corp),799001416(hr-share-acc...@miovision.corp),799000512(domain
adm...@miovision.corp),799000513(domain
us...@miovision.corp),799002464(it -
adm...@miovision.corp),799002469(kloperat...@miovision.corp),799002468(kladm...@miovision.corp),*176820(admins),176824(ad_admins)*

sdainard-ad...@miovision.corp@ubu1310:~$ sudo su
[sudo] password for sdainard-ad...@miovision.corp:
root@ubu1310:/home/miovision.corp/sdainard-admin#


Sudo rule (I had to create this, apparently its a default rule, but
didn't exist in my install on RHEL7 beta):
   Rule name: All
   Enabled: TRUE
   Host category: all
   Command category: all
   RunAs User category: all
   RunAs Group category: all
   User Groups: ad_admins


Can you tell me more information about admins and ad_admins groups and 
sdainard-admin? I would like to know how the membership is configured 
and what is their relation to AD. Dump of ipa user-show and ipa 
group-show should be enough, I think.




I saw the new dns update option (and refresh timers!), thanks.

*Steve Dainard *
IT Infrastructure Manager
Miovision <http://miovision.com/> | /Rethink Traffic/

*Blog <http://miovision.com/blog>  | **LinkedIn
<https://www.linkedin.com/company/miovision-technologies>  | Twitter
<https://twitter.com/miovision>  | Facebook
<https://www.facebook.com/miovision>*

Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener,
ON, Canada | N2C 1L3
This e-mail may contain information that is privileged or confidential.
If you are not the intended recipient, please delete the e-mail and any
attachments and notify us immediately.


On Tue, Feb 18, 2014 at 5:27 AM, Pavel Březina mailto:pbrez...@redhat.com>> wrote:

On 02/17/2014 10:29 PM, Steve Dainard wrote:

I can't reproduce consistently on any OS including Fedora 20,
but I was
able to trigger the issue on a Ubuntu 13.10 client.

sssd: 1.11.1

sudo: 1.8.6p3-0ubuntu3

I have only just enabled the sudo logging so it should only
contain the
events below:

sdainard-ad...@miovision.corp@__ubu1310:~$ sudo su
[sudo] password for sdainard-ad...@miovision.corp:
sdainard-ad...@miovision.corp is not allowed to run sudo on ubu1310.
   This incident will be reported.
sdainard-ad...@miovision.corp@__ubu1310:~$ sudo su
[sudo] password for sdainard-ad...@miovision.corp:
root@ubu1310:/home/miovision.__corp/sdainard-admin#

Files attached outside of list.


Hi,
thank you for the logs. Can you also send me output of command "id
sdainard-admin" (also check if group membership is correct) and
definition of the sudo rule please?

Also you may want to fix the following (unrelated) warning:
Deprecation warning: The option ipa_dyndns_update is deprecated and
should not be used in favor of dyndns_update




___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Sudo default options

[Pavel Březina]

On 10/05/2015 10:58 AM, Andreas Calminder wrote:

Hi,
guessing this is a quite frequent question, but I can't find any solid
information about the topic.
I want to specify a set of default sudo options so I don't have to
specify these options for every other sudo rule I create.
There's supposed to be a magic "defaults" rule.
This old document
(https://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf) 
suggests
it's cn=defaults,ou=sudorules,dc=example,dc=com which doesn't exist in
my ipa 4.1 installation others suggest it's under
ou=sudoers,dc=example,dc=com when poking around in ldap it looks like it
could also be cn=sudorules,cn=sudo,dc=example,dc=com, but there is no
way to be sure. Also, might it be as simple as create a defaults rule in
the webui or cli with the default options set or is this a ldapmodify
action?


Hi,
just create a sudo rule named "defaults" through ipa cli or wui.

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] sudo rules do not seem to work

[Pavel Březina]

On 10/07/2015 10:03 AM, Jakub Hrozek wrote:

On Tue, Oct 06, 2015 at 06:28:14PM +0200, Karl Forner wrote:

Hello,

I had assumed sudo rules worked because I have an "allow_all for admins"
sudo rule that seemed to work, but I wonder if there is an implicit rule
for the special group admins ?


Because I have tried to replicate this allow_all rule for for other user
groups, and it does not seem to work at all.
What's strange is that "sudo -l"  report the appropriate rules, but they do
not work.

For instance, some users have: (ALL) ALL listed with sudo -l, but they can
not use sudo.

My user has:
 (root) NOPASSWD: /usr/bin/git status, /usr/local/bin/git status
 (ALL) ALL
 (root) NOPASSWD: /bin/chgrp qbstaff *, /bin/chmod g[+-]* *, /bin/chmod
-R g[+-]* *
 (ALL) NOPASSWD: /usr/bin/less
 (ALL) ALL

but I'm prompted a password when doing "sudo /usr/bin/less".

How can I debug this ?


Pavel (CC) has a nice sudo debug howto, maybe it would be helpful?


Hi,
you are prompted for password because (ALL) ALL rule is applied because 
of last-match rule. See: 
http://www.sudo.ws/man/1.8.13/sudoers.ldap.man.html sudoOrder.



--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] sudo rules do not seem to work

[Pavel Březina]

On 10/08/2015 04:09 PM, Karl Forner wrote:

Sorry I had disabled the emailing, just was your answers in the archives.



How can I debug this ?



Pavel (CC) has a nice sudo debug howto, maybe it would be helpful?


Where is it ? Do you mean the slide
"FreeIPA Training Series: Obtaining debugging information" from
https://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf
?

Thanks !
Karl



It is not yet publicly available.

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] (no subject)

[Pavel Březina]

On 10/08/2015 04:26 PM, Karl Forner wrote:

Hi,



you are prompted for password because (ALL) ALL rule is applied because of last-match 
rule. > > > See: http://www.sudo.ws/man/1.8.13/sudoers.ldap.man.html sudoOrder.


Ok. I updated the rules to use a sudoorder attribute of 100 for the
/usr/bin/less sudo rule.
Now, if I type in a terminal:
%sudo -l
Matching Defaults entries for karl on midgard:
 env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User karl may run the following commands on :
 (ALL) ALL
 (root) NOPASSWD: /usr/bin/git status, /usr/local/bin/git status
 (ALL) ALL
 (ALL) NOPASSWD: /usr/bin/less

so my less rule is the last one. So far so good.

%sudo -l less
/usr/bin/less

but if I type in a new terminal:
%sudo less .bashrc
[sudo] password for karl:

I am prompted to type in a password.

So there seems to be a problem, right ?

Regards,
Karl



Hi,
we have a bug in sssd in versions prior 1.13.1:
https://fedorahosted.org/sssd/ticket/2682

where sudoOrder attribute is treated the other ways around. Please, try 
inverting the order. What version of sssd do you use?


--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] HOWTO: Troubleshooting SUDO

[Pavel Březina]

Hi,
I just submitted a sudo troubleshooting guide [1]. If you find anything 
missing, please, let me know.


[1] https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] (no subject)

[Pavel Březina]

On 10/09/2015 01:36 PM, Karl Forner wrote:

Ok, that was it:
sssd Version: 1.12.5-1~trusty1

I inverted the sudoOrders:
sudo -l
Matching Defaults entries for karl on :
 env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User karl may run the following commands on :
 (ALL) NOPASSWD: /usr/bin/less
 (root) NOPASSWD: /usr/bin/git status, /usr/local/bin/git status
 (root) NOPASSWD: /bin/chgrp qbstaff *, /bin/chmod g[+-]* *,
/bin/chmod -R g[+-]* *
 (ALL) ALL
 (ALL) ALL


and I can use sudo less without password.

Thanks a lot.


Thanks. Please, keep in mind that we changed the default to the correct 
order in sssd 1.13.1. Therefore if you update sssd you will either have 
to invert the order again or set sudo_inverse_order = true in [sudo] in 
/etc/sssd/sssd.conf.





On Thu, Oct 8, 2015 at 5:26 PM, Pavel Březina  wrote:

On 10/08/2015 04:26 PM, Karl Forner wrote:


Hi,



you are prompted for password because (ALL) ALL rule is applied because
of last-match rule. > > > See:
http://www.sudo.ws/man/1.8.13/sudoers.ldap.man.html sudoOrder.



Ok. I updated the rules to use a sudoorder attribute of 100 for the
/usr/bin/less sudo rule.
Now, if I type in a terminal:
%sudo -l
Matching Defaults entries for karl on midgard:
  env_reset, mail_badpass,

secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User karl may run the following commands on :
  (ALL) ALL
  (root) NOPASSWD: /usr/bin/git status, /usr/local/bin/git status
  (ALL) ALL
  (ALL) NOPASSWD: /usr/bin/less

so my less rule is the last one. So far so good.

%sudo -l less
/usr/bin/less

but if I type in a new terminal:
%sudo less .bashrc
[sudo] password for karl:

I am prompted to type in a password.

So there seems to be a problem, right ?

Regards,
Karl



Hi,
we have a bug in sssd in versions prior 1.13.1:
https://fedorahosted.org/sssd/ticket/2682

where sudoOrder attribute is treated the other ways around. Please, try
inverting the order. What version of sssd do you use?



--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] (no subject)

[Pavel Březina]

On 10/09/2015 01:40 PM, Karl Forner wrote:

Thanks. Please, keep in mind that we changed the default to the correct
order in sssd 1.13.1. Therefore if you update sssd you will either have to
invert the order again or set sudo_inverse_order = true in [sudo] in
/etc/sssd/sssd.conf.


ok. I don't think there's an easy way to upgrade sssd right now with
ubuntu 14.04.
Is-it possible to set sudo_inverse_order = true with my current
version, i.e. even if it is not yet recognized ?


SSSD will run but some tools that touch sssd.conf may have problems (for 
example I think authconfig will fail).













On Thu, Oct 8, 2015 at 5:26 PM, Pavel Březina  wrote:


On 10/08/2015 04:26 PM, Karl Forner wrote:



Hi,



you are prompted for password because (ALL) ALL rule is applied because
of last-match rule. > > > See:
http://www.sudo.ws/man/1.8.13/sudoers.ldap.man.html sudoOrder.




Ok. I updated the rules to use a sudoorder attribute of 100 for the
/usr/bin/less sudo rule.
Now, if I type in a terminal:
%sudo -l
Matching Defaults entries for karl on midgard:
   env_reset, mail_badpass,


secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User karl may run the following commands on :
   (ALL) ALL
   (root) NOPASSWD: /usr/bin/git status, /usr/local/bin/git status
   (ALL) ALL
   (ALL) NOPASSWD: /usr/bin/less

so my less rule is the last one. So far so good.

%sudo -l less
/usr/bin/less

but if I type in a new terminal:
%sudo less .bashrc
[sudo] password for karl:

I am prompted to type in a password.

So there seems to be a problem, right ?

Regards,
Karl



Hi,
we have a bug in sssd in versions prior 1.13.1:
https://fedorahosted.org/sssd/ticket/2682

where sudoOrder attribute is treated the other ways around. Please, try
inverting the order. What version of sssd do you use?





--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Sudo Rules Help

[Pavel Březina]

On 11/11/2015 03:24 PM, Branden Coates wrote:

I have a few issues with sudo rules(FreeIPA 4.1.4-4 on Fedora 22) that I
would greatly appreciate some help with. The core of the issue is that
sudo rules fail to work when using ldap instead of ipa when you assign
user groups and host groups to the sudo rule in place of explicitly
adding users and hosts to the sudo rule. The reason for needing to use
ldap over ipa is due to the organization requiring 2fa for all users via
OTP tokens. We have a mix of cent 5 to 7 systems, not all can be
immediately upgraded, so with cent 5 and 6 nodes ldap must be used
instead of ipa to support 2fa.
Explicitly assigning users and hosts to sudo rules is also unmanageable,
the organization has hundreds of employees and multiple thousands of
servers. Utilizing the host and user groups is a must.

On cent 7 the default sssd.conf generated by FreeIPA works, 2fa works by
default and the sssd.conf is using the ipa directives as well to parse
user and host groups on sudo rules. Everything here works as expected.

In cent 6 to allow 2fa to work the conf has to be updated to use ldap
instead of ipa. In the process this seems to break the ability to search
user and host groups on sudo rules. Users and hosts explicitly defined
for the sudo rules still work so the clients can see the rules, they
just do not seem to want to look within the groups that may be assigned
to the rules. I moved the original sssd.conf created by FreeIPA using
the ipa directives and sudo works as expected, but 2fa is not possible
like this.

Cent 5 is entirely incapable of using the sudo rules with user and host
groups since sudo lacks sssd support in cent 5 and depends on
/etc/ldap.conf to work. However like cent 6, users and hosts explicitly
defined for the sudo rules still work, so I presume fixing the sudo
rules with cent 6 on ldap would fix them here as well.

Can anyone else confirm this behavior, and if so can anyone suggest any
possible fixes or workarounds? I have attached the modified Cent6 and
Cent 5 configs for sssd and ldap inline below(first time mailing, if
inline is not ok please let me know what is preferable for future


Hi,
welcome to the list! I personally prefer receiving it as an attachment, 
since it is more convenient for me to organize and read.



reference). Currently testing using the following versions:
CentOS Linux release 7.1.1503 (Core)
CentOS release 6.7 (Final)
CentOS release 5.11 (Final)

Cent 6 /etc/sssd/sssd.conf:

#SSSD client configuration file.
[domain/domain]
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
autofs_provider = ldap
sudo_provider = ldap



binddn = 
bindpw = 
scope = sub
sudoers_base = ou=SUDOers,dc=,dc=com
tls_cacertfile = /etc/ipa/ca.crt
tls_checkpeer = yes
tls_reqcert = demand
ssl = start_tls


^ these are not sssd options thus it should not be in sssd.conf



ldap_schema = rfc2307bis
ldap_uri = _srv_,ldap://.:389
ldap_search_base = dc=,dc=com
ldap_user_search_base = cn=users,cn=accounts,dc=,dc=com
ldap_group_search_base = cn=groups,cn=accounts,dc=,dc=com
ldap_sudo_search_base = ou=SUDOers,dc=,dc=com

enumerate = True
cache_credentials = True

ldap_tls_cacertdir = /etc/ipa/
ldap_tls_cacert = /etc/ipa/ca.crt
ldap_tls_reqcert = demand
ldap_id_use_start_tls = True

krb5_realm = 


I do not see anything wrong here at first sight. Can you send also 
sssd_sudo.log and sssd_$domain.log please?




[sssd]
services = nss, sudo, pam, ssh, autofs
config_file_version = 2
domains = domain

[nss]
homedir_substring = /home
filter_users = root,named,avahi,haldaemon,dbus,radiusd,news,nscd

[pam]

[sudo]

[autofs]

[ssh]

[pac]

[ifp]


Cent 5 /etc/sssd/sssd.conf:

#SSSD client configuration file.
[domain/domain]
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
autofs_provider = ldap

ldap_schema = rfc2307bis
ldap_uri = _srv_,ldap://.:389
ldap_search_base = dc=,dc=com
ldap_user_search_base = cn=users,cn=accounts,dc=,dc=com
ldap_group_search_base = cn=groups,cn=accounts,dc=,dc=com

enumerate = True
cache_credentials = True

ldap_tls_cacertdir = /etc/ipa/
ldap_tls_cacert = /etc/ipa/ca.crt
ldap_tls_reqcert = demand
ldap_id_use_start_tls = True

krb5_realm = 

[sssd]
services = nss, pam
config_file_version = 2
domains = domain

[nss]
homedir_substring = /home
filter_users = root,named,avahi,haldaemon,dbus,radiusd,news,nscd

[pam]


Cent 5 /etc/ldap.conf:

#LDAP client configuration file.
uri ldap://.:389
base dc=,dc=com
ldap_version 3

tls_cacertfile /etc/ipa/ca.crt
tls_checkpeer yes
ssl start_tls

binddn 
bindpw 
timelimit 5
bind_timelimit 15

sudoers_base ou=SUDOers,dc=,dc=com


Thank you
Brande




--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Sudo ALL rule

[Pavel Březina]

On 05/31/2016 11:19 AM, Tony Brian Albers wrote:

Hi guys,

I'm implementing FreeIPA to auhenticate users on a small HPC cluster
here. For a few of these I need a sudo rule that in essence does the
same as the standard ALL(ALL) rule. How do I implement that in FreeIPA?

I've found some links/guides on the net, but they don't seem appropriate
for our version, 4.2.0

Any help is appreciated.

/tony


Hi,
the IPA alternative to keyword all is category "all". The following 
command should do what you want:


$ ipa sudorule-add allow-all --usercat=all --hostcat=all --cmdcat=all

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Sudo not working

[Pavel Březina]

On 10/31/2012 07:20 PM, Rob Crittenden wrote:

Bret Wortman wrote:

F17.


I think you want /etc/ldap.conf then. The easiest way to be sure the
right file is being used is to add sudoers_debug 1 to the file. This
will present a lot of extra output so you'll know the file is being read.

rob


Hi,
I think the easiest way to determine the config file is:
# sudo -V | grep ldap.conf
ldap.conf path: /etc/ldap.conf

(sudo must be executed under root account)





On Wed, Oct 31, 2012 at 2:04 PM, Rob Crittenden mailto:rcrit...@redhat.com>> wrote:

Bret Wortman wrote:

I had enabled debugging of sudo but am not clear on where that
debugging
is going. It's not stdout, and I'm not seeing anything in
/var/log/messages.

I'll try switching to SSS and see what that gets me.


What distro is this? If it is RHEL 6.3 then put the configuration
into /etc/sudo-ldap.conf instead of /etc/nslcd. The docs are
incorrect (we are working on getting them fixed).

rob



On Wed, Oct 31, 2012 at 1:33 PM, Stephen Gallagher
mailto:sgall...@redhat.com>
>> wrote:

 On Wed 31 Oct 2012 11:53:15 AM EDT, Bret Wortman wrote:

 I'm pretty certain there's a painfully simple solution
to this that
 I'm not seeing, but my current configuration isn't
picking up the
 freeipa sudoer rule that I've set.

 /etc/nsswitch.conf specifies:
   sudoers:files ldap

 /etc/nslcd.conf contains:

 binddn
uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me

 bindpw password

 ssl start_tls
 tls_cacertfile /etc/ipa/ca.crt
 tls_checkpeer yes

 bind_timelimit 5
 timelimit 15

 uri ldap://fs1.wedgeofli.me 

 

 sudoers_base ou=SUDOers,dc=wedgeofli,dc=me


 The sssd_DOMAIN.log file contains this when I try to
sudo:


 

 The SSSD logs aren't showing anything wrong because they
have
 nothing to do with the execution of the SUDO rules in this
 situation. All the SSSD is doing is verifying the
authentication
 (when sudo prompts you for your password).

 The problem with the rule is most likely happening inside
SUDO
 itself. When you specify 'sudoers: files, ldap' in
nsswitch.conf,
 it's telling SUDO to use its own internal LDAP driver to
look up the
 rules. So you need to check sudo logs to see what's
happening
 (probably you will need to enable debug logging in
/etc/sudo.conf).

 Recent versions of SUDO (1.8.6 and later) have support for
setting
 'sudoers: files, sss' in nsswitch.conf which DOES use SSSD
(1.9.0
 and later) for lookups (and caching) of sudo rules.




--
Bret Wortman
The Damascus Group
Fairfax, VA
http://bretwortman.com/
http://twitter.com/BretWortman




--
Bret Wortman
The Damascus Group
Fairfax, VA
http://bretwortman.com/
http://twitter.com/BretWortman



_
Freeipa-users mailing list
Freeipa-users@redhat.com 
https://www.redhat.com/__mailman/listinfo/freeipa-users






--
Bret Wortman
The Damascus Group
Fairfax, VA
http://bretwortman.com/
http://twitter.com/BretWortman



___
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


___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Managing Sudo through FreeIPA

[Pavel Březina]

On 11/08/2012 01:13 AM, Dmitri Pal wrote:

On 11/07/2012 04:28 PM, William Muriithi wrote:

Hello

I have been trying to setup user access through sudo file managed by
FreeIPA and it don't seem to be working.  I am not sure how to go
about fixing it, but I guess the best place to start is ask what I
should expect the IPA installation script should set up and what
should be done manually

[root@demo2 wmuriithi]# rpm -qa | grep sssd
sssd-client-1.8.0-32.el6.x86_64
sssd-1.8.0-32.el6.x86_64
[root@demo2 wmuriithi]#



[root@demo2 wmuriithi]# rpm -qa | grep sudo
sudo-1.7.4p5-13.el6_3.x86_64

The only errors related to sudo that I can find is on apache error logs

[Wed Nov 07 13:16:18 2012] [error] ipa: INFO: ad...@example.loc:
sudorule_add_user(u'read_only_viewiers', all=False, raw=False,
version=u'2.34', group=(u'operations',)): SUCCESS
[Wed Nov 07 13:54:44 2012] [error] ipa: ERROR: release_ipa_ccache:
ccache_name (FILE:/var/run/ipa_memcached/krbcc_3988) != KRB5CCNAME
environment variable (FILE:/tmp/krb5cc_apache_NB7pph)
[Wed Nov 07 13:54:44 2012] [error] ipa: INFO: ad...@example.loc:
sudorule_find(None, sizelimit=0, pkey_only=True): SUCCESS
[Wed Nov 07 13:54:44 2012] [error] ipa: INFO: ad...@example.loc:
batch: sudorule_show(u'Full_Access', all=True): SUCCESS
[Wed Nov 07 13:54:44 2012] [error] ipa: INFO: ad...@example.loc:
batch: sudorule_show(u'read_only_viewiers', all=True): SUCCESS
[Wed Nov 07 13:54:44 2012] [error] ipa: INFO: ad...@example.loc:
batch: sudorule_show(u'developers', all=True): SUCCESS
[Wed Nov 07 13:54:44 2012] [error] ipa: INFO: ad...@example.loc:
batch: sudorule_show(u'operation', all=True): SUCCESS
[Wed Nov 07 13:54:44 2012] [error] ipa: INFO: ad...@example.loc:
batch(({u'params': [[u'Full_Access'], {u'all': True}], u'method':
u'sudorule_show'}, {u'params': [[u'read_only_viewiers'], {u'all':
True}], u'method': u'sudorule_show'}, {u'params': [[u'developers'],
{u'all': True}], u'method': u'sudorule_show'}, {u'params':
[[u'operation'], {u'all': True}], u'method': u'sudorule_show'})):
SUCCESS
[Wed Nov 07 13:54:50 2012] [error] ipa: INFO: ad...@example.loc:
sudorule_show(u'read_only_viewiers', rights=True, all=True): SUCCESS


I created the user as below and associated it with a group, which I
then allowed to use less for reading file.  As you can see below, it
seem to does not work.

Nov  7 16:05:42 demo2 sudo: pam_sss(sudo:auth): authentication
success; logname=williamm uid=0 euid=0 tty=/dev/pts/2 ruser=williamm
rhost= user=williamm
Nov  7 16:05:43 demo2 sudo: williamm : user NOT in sudoers ; TTY=pts/2
; PWD=/home/wmuriithi ; USER=root ; COMMAND=/usr/bin/less
/var/log/secure


- My question is, does the client install script take care of sudo
configuration or is that done manually?  I don't see any sudo related
flag on the client installation script.

- I have tried configuring sssd for sudo use and it didn't go well.
Last time I messed around with LDAP managed sudo, I have to install a
LDAP capable sudo package.  The ipa-client install did not install
this package. Does IPA sudo management work differently?

- Where would I check for logs?  I checked sssd logs and they are empty.

- I am missing the basedn configuration on  sssd configuration.  From
this bug, it should have been setup by installer, oddly though it was
not setup and the bug is closed. I attempted to fix it by adding the
line below but it make sudo completely unusable.  It could not find
any valid users apparently

https://fedorahosted.org/freeipa/ticket/932

ldap_netgroup_search_base = cn=ng,cn=compat,dc=example,dc=loc

Nov  7 16:05:42 demo2 sudo: pam_sss(sudo:auth): authentication
success; logname=williamm uid=0 euid=0 tty=/dev/pts/2 ruser=williamm
rhost= user=williamm
Nov  7 16:05:43 demo2 sudo: williamm : user NOT in sudoers ; TTY=pts/2
; PWD=/home/wmuriithi ; USER=root ; COMMAND=/usr/bin/less
/var/log/secure


Any pointers on why we are going?

Thank you a lot in advance.

William


[root@ipa1-yyz-int wmuriithi]# ipa sudocmd-add --desc='For reading log
files' '/usr/bin/less'
--
Added Sudo Command "/usr/bin/less"
--
   Sudo Command: /usr/bin/less
   Description: For reading log files
[root@ipa1-yyz-int wmuriithi]# ipa sudocmdgroup-add --desc='Read Only
Commands' readonly
---
Added Sudo Command Group "readonly"
---
   Sudo Command Group: readonly
   Description: Read Only Commands
[root@ipa1-yyz-int wmuriithi]# ipa sudocmdgroup-add-member
--sudocmds='/usr/bin/less' readonly
   Sudo Command Group: readonly
   Description: Read Only Commands
   Member Sudo commands: /usr/bin/less
-
Number of members added 1
-
[root@ipa1-yyz-int wmuriithi]# ipa sudorule-add testing_viewiers
---
Added Sudo Rule "testing_viewiers"
---
   Rule name: testing_viewiers
   Enabled: TRUE

Re: [Freeipa-users] sudo rules are not active immediatly

[Pavel Březina]

On 02/08/2017 11:59 AM, Nathanaël Blanchet wrote:

Hello,
on latest IPA, when adding a command to a rule or a sudo option for
example, the change is not active on the user session.
For example, after removing !authenticate option, I still can execute
sudo commands without password.
I tried to logout and relogin, but nothing changes, but on a new vm
where never logeed in before it wroks.
Is there a cache or somting to do so as to commands to be immediatly
available?



Hi,
sudo rules are cache on the client and refresh happens periodically. We 
have several update mechanisms that deals with finding new rules, 
deleting non-existent ones and updating expired but it cannot be 
performed on desired at the moment. We have a ticket for that [1]. 
Please see 'man sssd-sudo' to get better understanding how it works.


It is possible to expired cached rules with sss_cache. This won't find 
you newly added rules but it will fetch updated rules and removed 
deleted ones.


[1] https://fedorahosted.org/sssd/ticket/2884

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] sudo rules are not active immediatly

[Pavel Březina]

On 02/08/2017 04:03 PM, Nathanaël Blanchet wrote:



Le 08/02/2017 à 13:00, Pavel Březina a écrit :

On 02/08/2017 11:59 AM, Nathanaël Blanchet wrote:

Hello,
on latest IPA, when adding a command to a rule or a sudo option for
example, the change is not active on the user session.
For example, after removing !authenticate option, I still can execute
sudo commands without password.
I tried to logout and relogin, but nothing changes, but on a new vm
where never logeed in before it wroks.
Is there a cache or somting to do so as to commands to be immediatly
available?



Hi,
sudo rules are cache on the client and refresh happens periodically.
We have several update mechanisms that deals with finding new rules,
deleting non-existent ones and updating expired but it cannot be
performed on desired at the moment. We have a ticket for that [1].
Please see 'man sssd-sudo' to get better understanding how it works.


it's said that sssd-sudo has been created to be near of the local
sudoers functionnment. So I suppose the three described mechanisms are
intended to converge to a near realtime rule change.
It's true that waiting for an undefinied time, rules become available...
but is there an estimated time of availibility? Is it rather 15min or
one hour (I suppose beyond is not usable)

It is possible to expired cached rules with sss_cache. This won't find
you newly added rules but it will fetch updated rules and removed
deleted ones.

[1] https://fedorahosted.org/sssd/ticket/2884


Depending on how often does your environment change, you can adjust sudo 
rules updates with following options:


- entry_cache_sudo_timeout -- how long is the cache ruled valid, when 
the timeout is exceeded the rule is updated from ldap


- ldap_sudo_smart_refresh_interval -- periodical update that fetches 
newly added or modified rules from the last lookup (uses 
modifyTimestamp/entryUSN operational attribute to do so)


- ldap_sudo_full_refresh_interval -- periodical update that simply 
deletes current cached rules and downloads those stored in ldap


--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] sudo NOPASSWD for a single command

[Pavel Březina]

On 02/23/2017 03:43 PM, Auerbach, Steven wrote:

Yes, I implemented in Policy -> Sudo -> Sudo Commands as:

Sudo Command:  NOPASSWD: /sbin/vgs


NOPASSWD is used in /etc/sudoers. In IPA, create a sudo option 
"!authenticate" instead.






The script (executed by a non-root, administrative group user on an
enrolled host) specifies:

….

hostname >> statresults.txt

cat /etc/redhat-release >> statresults.txt

uname -r >> statresults.txt

printf "\n " >> statresults.txt

sudo vgs >> statresults.txt

…..

Running the script I still was prompted for a password. So I guess this
does not work.



*From:* Jason B. Nance [mailto:ja...@tresgeek.net]
*Sent:* Wednesday, February 22, 2017 11:59 AM
*To:* Auerbach, Steven 
*Cc:* freeipa-users@redhat.com
*Subject:* Re: [Freeipa-users] sudo NOPASSWD for a single command





We have a script stored on a particular server in our realm that
executes a number of non-privileged commands and are wanting to add
/sbin/vgs command. The script uses SSH to then execute the same set
of commands on all the servers in the realm.

The owner of the script is in the administrator group and there are
sudoer commands for the administrator group in general.  We need to
place a rule for this one command for either this group or the
script owner to run NOPASSWD.

Where and how would I specify that in the IPA admin console?

Have you tried creating your command in IPA as "NOPASSWD: /sbin/vgs"
(Policy -> Sudo -> Sudo Commands)?







--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project