Re: [Freeipa-users] Sudo privilege inheritance in FreeIPA (3.0.x branch)

[sysadmin ofdoom]

Sorry for not defining the question.

The question for this is: Are sudo rules supposed to be inherited in the
same manner as HBAC rules?

>From the case above, all my HBAC rules are working fine with indirect
membership, but sudo only works with direct membership. I also saw the Tech
preview SSSD packages for RHEL 6.8. I tried those too and verified that the
issue is still present.



On Wed, Jan 27, 2016 at 9:36 AM, sysadmin ofdoom <
nix125432512689...@gmail.com> wrote:

> I am trying to implement FreeIPA in a larger environment. Due to the
> complexity of the environment I've been constructing a user group structure
> such that i have groups at the following levels:
>
> project --> project_at_site --> project_site_vendor
>
> HBAC rules are defined at the lowest level (vendor at site) and associated
> with a host group at the same level.
>
> Each of the above user group levels will have a corresponding sudo group.
> (Used to provide a vendor access to servers  the vendor supports at a
> specific site at a moments notice)
>
> HBAC rules are propagating up the chain correctly.
>
> When a user is added to a top level group (e.g. project or project-sudo)
> the indirect membership shows up for both Sudo and HBAC rules.
>
> The problem is that I can't get the sudo privileges to work when the user
> shows indirect membership for the sudo rule. If i make the user a direct
> member of the sudo rule, i can use sudo.
>
> As I've looked at debug logs, i was able to see that the query used when i
> was identical when i was successful at using sudo and when i i got denied.
> The difference is  the failure would have a message like
> [sudosrv_get_sudorules_from_cache] (0x0400): Returning 1 rules for [
> u...@example.com]  The successes returned 2 rules.
>
> The only change made between the success and failure was making the user a
> direct member of the sudo rule where the failure was an indirect member.
>
> Thanks for any help!
>
>
>
>
>
>
-- 
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] [freeipa-users] Problem managing Autofs with FreeIPA

[Jon]

Hello,

I am attempting to configure autofs to automount home directories from an
NFS server.

I'm following these instructions as this was the only contiguous "here's
what you need to do" instructions as the FreeIPA and Fedora documentation
seems to contradict itself, and there's no clear cut a. then b. then c.
 (Admittedly, this is my first foray into managing home dirs this way, so
I'm learning all around :)  but I need a bit of direction...)

First things first, can anyone confirm these directions are correct please?


http://blog.delouw.ch/2015/03/14/using-ipa-to-provide-automount-maps-for-nfsv4-home-directories/

I'm going to assume they are for the purposes of the rest of the post.

I'm currently working with three servers:
freeipa01 - The FreeIPA server
home-dir01 - The Home directory NFS server
ipa-test01 - My test server where I'm making changes/trying to mount the
home directory.

ipa-test01 is the only CentOS 6.5 machine (no choice, it's the "production
blessed" image), freeipa01 and home-dir01 are both CentOS7.

Following those above linked instructions, I have created the following
autmount configurations:

Automount Configuration:
>> [root@ipa-test01 ~]# ipa automountlocation-find
>> 
>> 1 automount location matched
>> 
>>   Location: default
>> 
>> Number of entries returned 1
>> 
>>
>> [root@ipa-test01 ~]# ipa automountmap-find
>> Location: default
>> 
>> 3 automount maps matched
>> 
>>   Map: auto.direct
>>
>>   Map: auto.home
>>
>>   Map: auto.master
>> 
>> Number of entries returned 3
>> 
>>
>> [root@ipa-test01 ~]# ipa automountkey-find default auto.home
>> ---
>> 1 automount key matched
>> ---
>>   Key: *
>>   Mount information: -fstype=nfs4,rw,sec=krb5,soft,rsize=8192,wsize=8192
home-dir01.sub.domain.mydomain.com:/exports/home/&
>> 
>> Number of entries returned 1
>> 

Exports configuration:

>> [root@home-dir01 home]# cat /etc/exports
>> /exports/home  *(rw,no_root_squash,sec=sys:krb5:krb5i:krb5p)



At some point I generated this error.  I have been unable to reproduce
it...  Included for completeness of my reporting but I don't think it's
currently an issue.

>> Feb  1 15:43:19 ipa-test01 rpc.gssd[1371]: ERROR: No credentials found
for connection to server home-dir01.sub.domain.mydomain.com


Without an entry in /etc/hosts I receive the following error when
attempting to login as my domain user:

>> Feb  1 16:22:13 ipa-test01 kernel: type=1105 audit(1454361733.209:125):
user pid=1777 uid=0 auid=0 ses=1 msg='op=PAM:session_open acct="
j...@mydomain.com" exe="/usr/bin/sudo" hostname=? addr=?
terminal=/dev/pts/0 res=success'
>> Feb  1 16:22:22 ipa-test01 rpc.gssd[1371]: ERROR: unable to resolve
2605:1c00:50f2:300a::56ff::442a to hostname: Temporary failure in
name resolution
>> Feb  1 16:22:22 ipa-test01 rpc.gssd[1371]: ERROR: failed to read service
info
>> Feb  1 16:22:22 ipa-test01 rpc.gssd[1371]: ERROR: unable to resolve
192.168.10.250 to hostname: Name or service not known
>> Feb  1 16:22:22 ipa-test01 rpc.gssd[1371]: ERROR: failed to read service
info


So I added the entry in /etc/hosts for my nfs server (will fix in DNS, but
we use 3rd party DNS service that is not integrated with AD...), I get the
following error (repeated attempts to sudo), note the "res=success"

>> ipa-test01:/var/log/messages
>> Feb  1 16:16:38 ipa-test01 kernel: __ratelimit: 90 callbacks suppressed
>> Feb  1 16:16:38 ipa-test01 kernel: type=1123 audit(1454361398.936:92):
user pid=1632 uid=0 auid=0 ses=1 msg='cwd="/root" cmd="-sh" terminal=pts/0
res=success'
>> Feb  1 16:16:38 ipa-test01 kernel: type=1103 audit(1454361398.936:93):
user pid=1632 uid=0 auid=0 ses=1 msg='op=PAM:setcred acct="j...@mydomain.com"
exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success'
>> Feb  1 16:16:38 ipa-test01 kernel: type=1105 audit(1454361398.943:94):
user pid=1632 uid=0 auid=0 ses=1 msg='op=PAM:session_open acct="
j...@mydomain.com" exe="/usr/bin/sudo" hostname=? addr=?
terminal=/dev/pts/0 res=success'
>> Feb  1 16:16:38 ipa-test01 kernel: type=1106 audit(1454361398.944:95):
user pid=1632 uid=0 auid=0 ses=1 msg='op=PAM:session_close acct="
j...@mydomain.com" exe="/usr/bin/sudo" hostname=? addr=?
terminal=/dev/pts/0 res=success'
>> Feb  1 16:16:38 ipa-test01 kernel: type=1104 audit(1454361398.944:96):
user pid=1632 uid=0 auid=0 ses=1 msg='op=PAM:setcred acct="j...@mydomain.com"
exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success'
>> Feb  1 16:16:39 ipa-test01 kernel: type=1123 audit(1454361399.976:97):
user pid=1635 uid=0 auid=0 ses=1 msg='cwd="/root" cmd="-sh" terminal=pts/0
res=success'
>> Feb  1 16:16:39 ipa-test01 kernel: type=1103 audit(1454361399.976:98):
user pid=1635 

[Freeipa-users] ca install fails upgrading to 4.2.0

[Robert van Veelen]

Hi,
I'm trying to create an ipa replica from
ipa-server-3.0.0-47/pki-ca-9.0.3-45 to ipa-server-4.2.0-15/pki-ca-10.2.5-6
and cannot get the install to complete. The CS is configured as a sub to an
external CA. I keep getting the same error when running the
replica-install. Digging into pki-ca's debug log, I find the following
errors:

 java.lang.Exception: SystemCertsVerification: system certs verification
failure
&
 CertUtils: verifySystemCertByNickname() failed: caSigningCert cert-pki-ca

I've tried regenerating the source cacert.p12, upgrading pki-ca to latest,
etc. It just seems like the new replica is unable to verify the certs while
running selftests. any good tips for a next step to work out whats going on?

Thanks,

-rob
-- 
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] SSSD Crash Causing Inaccessibility

[Lukas Slebodnik]

On (29/01/16 14:08), Jeff Hallyburton wrote:
>Lukas,
>
>Installed versions of sssd:
>
># rpm -qa | grep -i sssd
>
>sssd-common-1.13.0-40.el7_2.1.x86_64
>
>sssd-ipa-1.13.0-40.el7_2.1.x86_64
>
>sssd-1.13.0-40.el7_2.1.x86_64
>
>sssd-krb5-common-1.13.0-40.el7_2.1.x86_64
>
>sssd-ad-1.13.0-40.el7_2.1.x86_64
>
>sssd-ldap-1.13.0-40.el7_2.1.x86_64
>
>sssd-proxy-1.13.0-40.el7_2.1.x86_64
>
>python-sssdconfig-1.13.0-40.el7_2.1.noarch
>
>sssd-client-1.13.0-40.el7_2.1.x86_64
>
>sssd-common-pac-1.13.0-40.el7_2.1.x86_64
>
>sssd-krb5-1.13.0-40.el7_2.1.x86_64
>
>No core dumps unfortunately.
>
That's stable version.
But on the other hand we do not test OOM.
Is there something interesting in /varlog/sssd/sssd.log?

LS

-- 
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] [SSSD-users] Re: heads-up: new code to fetch sudo rules from an IPA server coming to Fedora and RHEL-6

[Jakub Hrozek]

On Sun, Jan 31, 2016 at 09:58:40PM +0100, Michael Ströder wrote:
> Jakub Hrozek wrote:
> > the sssd's code that fetches sudo rules from the IPA server got an
> > overhaul recently. The search would no longer be performed against the
> > compat tree, but against IPA's native LDAP tree. This would have the
> > advantage that environments that don't use the slapi-nis' compat tree
> > for another reason (like old or non-Linux clients) would no longer
> > require slapi-nis to be running at all.
> 
> Frankly I don't understand this text. Especially I don't know what the terms
> "compat tree" and "IPA's native LDAP tree" really mean.

I'm sorry, I will try to rephrase.

If you add sudo rules to an IPA server using the "ipa sudorule"
commands, the LDAP objects are added to cn=sudorules,cn=sudo,$DC tree in
using a schema that is specific to IPA. The rule might look like this
one on my test server:
  dn: 
ipaUniqueID=c4bba598-9f5b-11e5-8750-525400676811,cn=sudorules,cn=sudo,dc=ipa,dc=test
  cn: readfiles
  ipaenabledflag: TRUE
  externaluser: jsmith
  ipaUniqueID: c4bba598-9f5b-11e5-8750-525400676811
  memberallowcmd: 
ipaUniqueID=cb15fdc6-9f5b-11e5-b9f5-525400676811,cn=sudocmds,cn=sudo,dc=ipa,dc=test
  objectClass: ipasudorule
  objectClass: ipaassociation

However, the client side (both the LDAP connector that is built-in to
sudo itself and the SSSD) only understood the schema as defined by
http://linux.die.net/man/5/sudoers.ldap

Therefore, there is a another subtree on the IPA server, rooted at
ou=sudoers,$DC. This subtree is often called the 'compat' tree, because
in was built with non-SSSD clients in mind. The objects are put into the
compat tree by the slapi-nis Directory Server plugin. The rule above would
be converted to:
dn: cn=readfiles,ou=sudoers,dc=ipa,dc=test
sudoUser: jsmith
objectClass: sudoRole
objectClass: top
sudoCommand: /usr/bin/less
cn: readfiles

However, this auto-generation does not come for free and in some
environments, the slapi-nis plugin was causing substantial load on the
server side. So we added code to the sssd's ipa_provider to handle the
objects stored at cn=sudorules,cn=sudo,$DC so that the slapi-nis plugin
can be disabled.

The functionality of the ipa's sudo_provider should stay the same, it's
just that it's now able to process a different schema and this change
allows the admin to disable the slapi-nis plugin (unless they need
another piece of its functionality, which is translating the user and
group objects into rfc2307 schema for legacy clients..)

> 
> Does this only affect the IPA provider?

Yes.

-- 
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] Sudo privilege inheritance in FreeIPA (3.0.x branch)

[sysadmin ofdoom]

I am trying to implement FreeIPA in a larger environment. Due to the
complexity of the environment I've been constructing a user group structure
such that i have groups at the following levels:

project --> project_at_site --> project_site_vendor

HBAC rules are defined at the lowest level (vendor at site) and associated
with a host group at the same level.

Each of the above user group levels will have a corresponding sudo group.
(Used to provide a vendor access to servers  the vendor supports at a
specific site at a moments notice)

HBAC rules are propagating up the chain correctly.

When a user is added to a top level group (e.g. project or project-sudo)
the indirect membership shows up for both Sudo and HBAC rules.

The problem is that I can't get the sudo privileges to work when the user
shows indirect membership for the sudo rule. If i make the user a direct
member of the sudo rule, i can use sudo.

As I've looked at debug logs, i was able to see that the query used when i
was identical when i was successful at using sudo and when i i got denied.
The difference is  the failure would have a message like
[sudosrv_get_sudorules_from_cache] (0x0400): Returning 1 rules for [
u...@example.com]  The successes returned 2 rules.

The only change made between the success and failure was making the user a
direct member of the sudo rule where the failure was an indirect member.

Thanks for any help!
-- 
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] [SSSD-users] heads-up: new code to fetch sudo rules from an IPA server coming to Fedora and RHEL-6

[Michael Ströder]

Jakub Hrozek wrote:
> the sssd's code that fetches sudo rules from the IPA server got an
> overhaul recently. The search would no longer be performed against the
> compat tree, but against IPA's native LDAP tree. This would have the
> advantage that environments that don't use the slapi-nis' compat tree
> for another reason (like old or non-Linux clients) would no longer
> require slapi-nis to be running at all.

Frankly I don't understand this text. Especially I don't know what the terms
"compat tree" and "IPA's native LDAP tree" really mean.

Does this only affect the IPA provider?

Ciao, Michael.

--
Michael Ströder
E-Mail: mich...@stroeder.com
http://www.stroeder.com




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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] [Centos7.2 Freeipa 4.2] browser : your session has expired

[Petr Vobornik]

On 01/31/2016 09:49 AM, wodel youchi wrote:

Hi,

I miss explained myself apparently, here it is:

I open a session with login/password, I do some work, I left it for a
while, the session disconnects which is normal.
I come back, I try to authenticate with login/password it keeps telling me
: your session has expired.

Regards.


Is there a time difference between a machine with browser and an IPA server?



2016-01-30 17:54 GMT+01:00 Alexander Bokovoy :




- Original Message -

Hi,

When accessing the webui of Freeipa from the browser using login

password, I

get your session has expired.


As a workaround I have to either :
- Delete the https certificate of the ipa server from the browser and

delete

history then relogin again.
- Restart ipa services : ipactl restart

- delete cookies in the browser corresponding to IPA server.


PS: The machine I am using to connect to the webui of freeipa is not

enrolled

in it, I am using login/pass to connect not kerberos.

Web UI session is set to 30 minutes or so.

--
/ Alexander Bokovoy








--
Petr Vobornik

--
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