[Freeipa-users] Please Provide the IPA Client Configuration Doc for Ubuntu 12.04, 14.04

[Visakh MV]

Hi Team,

Could you provide the client setup guide for Ubuntu systems. And we are
using FreeIPA 4.2.0 version.  it's been a while trying to find the document
for Ubuntu with latest version FreeIPA Server, even now can not find the
doc. so kindly provide the same doc via mail as soon as good.

even if tried some solution that could find out from internet as well but
still its not help us.

-- 

Thanks & Regards,

*Visakh m.v*

*Support Engineer*

Soffit Infrastructure Services (P) Ltd | Raj Bhavan | Power House Road |
Palarivattom|Kochi-25 | Kerala | India.

(M) +91-9497714447|(O) 0484-3045663,0484-3931393|Web:www.soffit.in

Managed Services | Technical Services | Infrastructure Consulting | Audits
& Assessments

DISCLAIMER : This email, which includes any attachments, is confidential,
may be privileged and is intended solely for the use of the named
recipient(s). If you are not the intended recipient, do not disclose,
distribute, or retain it, and please notify the sender immediately and
delete the e-mail. E-mail is not necessarily secure or error free. It is
your responsibility to ensure that e-mails are virus free. No one may
conclude a contract on behalf of SOFFIT by e-mail without express written
confirmation by a duly authorised representative of SOFFIT. Any views
expressed in this e-mail are not necessarily those of SOFFIT. SOFFIT
accepts no responsibility for any loss or damages arising in any way from
the use of this e-mail as a means of communication.
-- 
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] HBAC and AD users

[Lachlan Musicman]

I've updated all the relevant hosts and the FreeIPA server to the COPR sssd
1.14.0 release and the problem seems to have disappeared.

Cheers
L.

--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 15 July 2016 at 10:09, Lachlan Musicman  wrote:

> AH. I'm seeing a lot of this now.
>
> hbac_eval_user_element is returning the wrong number of groups.
>
> I just found another instance in my logs :
>
> (Fri Jul 15 08:39:04 2016) [sssd[be[unix.petermac.org.au]]]
> [hbac_eval_user_element] (0x1000): [23] groups for [SimpsonLachlan]
>
>
> IPA server
> [root@vmpr-linuxidm ~]# id simpsonlach...@petermac.org.au | tr "," "\n" |
> wc -l
> 41
>
> Host
> [root@papr-res-galaxy ~]# id simpsonlach...@petermac.org.au | tr "," "\n"
> |wc -l
> 41
>
>
> L.
>
> --
> The most dangerous phrase in the language is, "We've always done it this
> way."
>
> - Grace Hopper
>
> On 15 July 2016 at 09:45, Lachlan Musicman  wrote:
>
>>
>> On 14 July 2016 at 17:44, Sumit Bose  wrote:
>>
>>> On Thu, Jul 14, 2016 at 11:47:41AM +1000, Lachlan Musicman wrote:
>>> > Ok, I have some logs of sssd 1.13.0 not working. Same values as before:
>>> >
>>> > FreeIPA server: Centos 7, ipa 4.2, API_VERSION 2.156
>>> >
>>> > Installed Packages
>>> > Name: ipa-server
>>> > Arch: x86_64
>>> > Version : 4.2.0
>>> > Release : 15.0.1.el7.centos.17
>>> > Size: 5.0 M
>>> > Repo: installed
>>> > >From repo   : updates
>>> > Summary : The IPA authentication server
>>> >
>>> >
>>> > Successfully joined in one way trust to AD.
>>> >
>>> > Successfully have added hosts (Centos 7, sssd 1.13.0).
>>> >
>>> >
>>> > [root@vmpr-linuxidm ~]# ipa hbacrule-find
>>> > 
>>> > 5 HBAC rules matched
>>> > 
>>> >
>>> >   Rule name: allow_all
>>> >   User category: all
>>> >   Host category: all
>>> >   Service category: all
>>> >   Description: Allow all users to access any host from any host
>>> >   Enabled: FALSE
>>> >
>>> > ...
>>> >
>>> >   Rule name: ssh to galaxy
>>> >   Service category: all
>>> >   Description: Allows ssh to galaxy server
>>> >   Enabled: TRUE
>>> >   User Groups: ad_users
>>> >   Hosts: papr-res-galaxy.unix.petermac.org.au
>>> >
>>> >
>>> >
>>> >
>>> > With allow_all HBAC rule enabled, can login every time with
>>> >
>>> > ssh user@ad_domain@unix_host
>>> >
>>> > If I implement a HBAC rule "ssh to galaxy" as per above, with:
>>> >
>>> > ad_users is a POSIX group with a GID. It has one member, the group
>>> >
>>> > ad_external an external group with a single, external, member
>>> >
>>> > pmc-res-ipaus...@petermac.org.au
>>> >
>>> > which is an AD group containing all the users that should have access
>>> to
>>> > the host.
>>> >
>>> >
>>> > With allow_all disabled and "ssh to galaxy" enabled, some users can
>>> login
>>> > and some can't. There is no discernable pattern that might explain why
>>> some
>>> > are discriminated against.
>>> >
>>> > Here is the test from the server:
>>> >
>>> > [root@vmpr-linuxidm ~]# ipa hbactest --user=
>>> sandsjor...@petermac.org.au
>>> > --host=papr-res-galaxy.unix.petermac.org.au --service=sshd
>>> > 
>>> > Access granted: True
>>> > 
>>> >   Matched rules: ssh to galaxy
>>> >   Not matched rules: Computing Cluster
>>> >   Not matched rules: FACS Computing
>>> >
>>> > I've installed ipa-admintools on the host in question and got the same
>>> > result.
>>> >
>>> > To be on the safe side/tick all boxes, I have cleared the cache on the
>>> host
>>> > in question:
>>> >
>>> > systemctl stop sssd
>>> > sss_cache -E
>>> > systemctl start sssd
>>> >
>>> > and confirmed success with a status check.
>>> >
>>> > When the user tries to login, it fails.
>>> >
>>> > Log is here:
>>> >
>>> > http://dpaste.com/0VAFNPH
>>> >
>>> >
>>> > The top is where the negotiating starts to the best of my knowledge.
>>> >
>>> > The attempts fails, with no information that is useful to me:
>>> >
>>> > 230 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
>>> > [hbac_get_category] (0x0200): Category is set to 'all'.
>>> > 231 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
>>> > [hbac_thost_attrs_to_rule] (0x1000): Processing target hosts for rule
>>> [ssh
>>> > to galaxy]
>>> > 232 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
>>> > [hbac_shost_attrs_to_rule] (0x0400): Processing source hosts for rule
>>> [ssh
>>> > to galaxy]
>>> > 233 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
>>> > [hbac_eval_user_element] (0x1000): [3] groups for [
>>> > sandsjor...@petermac.org.au]
>>>
>>> According to the HBAC evaluation the user is a member of 3 groups. Is
>>> this the expected number?
>>>
>>> Can you check if 'id sandsjor...@petermac.org.au' returns the expected
>>> list of groups on the client and the IPA server? (The client does not
>>> talk to AD directly only to the IPA 

Re: [Freeipa-users] Error in selinux child: libsemanage can't parse spaces in AD user names

[Lachlan Musicman]

This line:

We have SELinux disabled on all of our servers, but we hadn't disabled this
check in sssd.conf. So we enabled it in sssd.conf and everything worked
fine.

Should read that we *disabled* selinux.

selinux_provider = none

Cheers
L.

--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 15 July 2016 at 11:27, Lachlan Musicman  wrote:

> Hey,
>
> While hunting this sssd/hbac/AD user problem, I noticed in the
> selinux_child.log a lot of errors that look like this:
>
> (Thu Jul 14 09:40:29 2016) [[sssd[selinux_child[5446 [libsemanage]
> (0x0020): could not parse seuser record
> (Thu Jul 14 09:40:29 2016) [[sssd[selinux_child[5446 [libsemanage]
> (0x0020): could not cache file database
> (Thu Jul 14 09:40:29 2016) [[sssd[selinux_child[5446 [libsemanage]
> (0x0020): could not enter read-only section
> (Thu Jul 14 09:40:29 2016) [[sssd[selinux_child[5446 [get_seuser]
> (0x0020): Cannot query for galaxy
> (Thu Jul 14 09:40:29 2016) [[sssd[selinux_child[5446 [libsemanage]
> (0x0020): expected character ':', but found 'j'
> (/etc/selinux/targeted/modules/tmp//seusers.final: 10):
> ellul ja...@petermac.org.au:unconfined_u:s0-s0:c0.c1023
> (Thu Jul 14 09:40:29 2016) [[sssd[selinux_child[5446 [libsemanage]
> (0x0020): could not parse seuser record
> (Thu Jul 14 09:40:29 2016) [[sssd[selinux_child[5446 [libsemanage]
> (0x0020): could not cache file database
> (Thu Jul 14 09:40:29 2016) [[sssd[selinux_child[5446 [libsemanage]
> (0x0020): could not enter read-only section
> (Thu Jul 14 09:40:29 2016) [[sssd[selinux_child[5446 [set_seuser]
> (0x0020): Cannot verify the SELinux user
> (Thu Jul 14 09:40:29 2016) [[sssd[selinux_child[5446 [main] (0x0020):
> Cannot set SELinux login context.
> (Thu Jul 14 09:40:29 2016) [[sssd[selinux_child[5446 [main] (0x0020):
> selinux_child failed!
> (Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [main] (0x0400):
> selinux_child started.
> (Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [main] (0x0400):
> context initialized
> (Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [main] (0x0400):
> performing selinux operations
> (Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [libsemanage]
> (0x0020): expected character ':', but found 'j'
> (/etc/selinux/targeted/modules/active//seusers.final: 10):
> ellul ja...@petermac.org.au:unconfined_u:s0-s0:c0.c1023
> (Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [libsemanage]
> (0x0020): could not parse seuser record
> (Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [libsemanage]
> (0x0020): could not cache file database
> (Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [libsemanage]
> (0x0020): could not enter read-only section
> (Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [get_seuser]
> (0x0020): Cannot query for simpsonlach...@petermac.org.au
> (Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [libsemanage]
> (0x0020): expected character ':', but found 'j'
> (/etc/selinux/targeted/modules/tmp//seusers.final: 10):
> ellul ja...@petermac.org.au:unconfined_u:s0-s0:c0.c1023
> (Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [libsemanage]
> (0x0020): could not parse seuser record
> (Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [libsemanage]
> (0x0020): could not cache file database
> (Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [libsemanage]
> (0x0020): could not enter read-only section
> (Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [set_seuser]
> (0x0020): Cannot verify the SELinux user
> (Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [main] (0x0020):
> Cannot set SELinux login context.
> (Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [main] (0x0020):
> selinux_child failed!
> (Thu Jul 14 10:37:14 2016) [[sssd[selinux_child[5585 [main] (0x0400):
> selinux_child started.
> (Thu Jul 14 10:37:14 2016) [[sssd[selinux_child[5585 [main] (0x0400):
> context initialized
> (Thu Jul 14 10:37:14 2016) [[sssd[selinux_child[5585 [main] (0x0400):
> performing selinux operations
> (Thu Jul 14 10:37:14 2016) [[sssd[selinux_child[5585 [libsemanage]
> (0x0020): expected character ':', but found 'j'
> (/etc/selinux/targeted/modules/active//seusers.final: 10):
> ellul ja...@petermac.org.au:unconfined_u:s0-s0:c0.c1023
> (Thu Jul 14 10:37:14 2016) [[sssd[selinux_child[5585 [libsemanage]
> (0x0020): could not parse seuser record
> (Thu Jul 14 10:37:14 2016) [[sssd[selinux_child[5585 [libsemanage]
> (0x0020): could not cache file database
> (Thu Jul 14 10:37:14 2016) [[sssd[selinux_child[5585 [libsemanage]
> (0x0020): could not enter read-only section
> (Thu Jul 14 10:37:14 2016) [[sssd[selinux_child[5585 [get_seuser]
> (0x0020): Cannot query for madhamshettiwar p...@petermac.org.au
> (Thu Jul 14 10:37:14 2016) [[sssd[selinux_child[5585 [libsemanage]
> (0x0020): expected 

[Freeipa-users] Error in selinux child: libsemanage can't parse spaces in AD user names

[Lachlan Musicman]

Hey,

While hunting this sssd/hbac/AD user problem, I noticed in the
selinux_child.log a lot of errors that look like this:

(Thu Jul 14 09:40:29 2016) [[sssd[selinux_child[5446 [libsemanage]
(0x0020): could not parse seuser record
(Thu Jul 14 09:40:29 2016) [[sssd[selinux_child[5446 [libsemanage]
(0x0020): could not cache file database
(Thu Jul 14 09:40:29 2016) [[sssd[selinux_child[5446 [libsemanage]
(0x0020): could not enter read-only section
(Thu Jul 14 09:40:29 2016) [[sssd[selinux_child[5446 [get_seuser]
(0x0020): Cannot query for galaxy
(Thu Jul 14 09:40:29 2016) [[sssd[selinux_child[5446 [libsemanage]
(0x0020): expected character ':', but found 'j'
(/etc/selinux/targeted/modules/tmp//seusers.final: 10):
ellul ja...@petermac.org.au:unconfined_u:s0-s0:c0.c1023
(Thu Jul 14 09:40:29 2016) [[sssd[selinux_child[5446 [libsemanage]
(0x0020): could not parse seuser record
(Thu Jul 14 09:40:29 2016) [[sssd[selinux_child[5446 [libsemanage]
(0x0020): could not cache file database
(Thu Jul 14 09:40:29 2016) [[sssd[selinux_child[5446 [libsemanage]
(0x0020): could not enter read-only section
(Thu Jul 14 09:40:29 2016) [[sssd[selinux_child[5446 [set_seuser]
(0x0020): Cannot verify the SELinux user
(Thu Jul 14 09:40:29 2016) [[sssd[selinux_child[5446 [main] (0x0020):
Cannot set SELinux login context.
(Thu Jul 14 09:40:29 2016) [[sssd[selinux_child[5446 [main] (0x0020):
selinux_child failed!
(Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [main] (0x0400):
selinux_child started.
(Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [main] (0x0400):
context initialized
(Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [main] (0x0400):
performing selinux operations
(Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [libsemanage]
(0x0020): expected character ':', but found 'j'
(/etc/selinux/targeted/modules/active//seusers.final: 10):
ellul ja...@petermac.org.au:unconfined_u:s0-s0:c0.c1023
(Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [libsemanage]
(0x0020): could not parse seuser record
(Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [libsemanage]
(0x0020): could not cache file database
(Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [libsemanage]
(0x0020): could not enter read-only section
(Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [get_seuser]
(0x0020): Cannot query for simpsonlach...@petermac.org.au
(Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [libsemanage]
(0x0020): expected character ':', but found 'j'
(/etc/selinux/targeted/modules/tmp//seusers.final: 10):
ellul ja...@petermac.org.au:unconfined_u:s0-s0:c0.c1023
(Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [libsemanage]
(0x0020): could not parse seuser record
(Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [libsemanage]
(0x0020): could not cache file database
(Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [libsemanage]
(0x0020): could not enter read-only section
(Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [set_seuser]
(0x0020): Cannot verify the SELinux user
(Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [main] (0x0020):
Cannot set SELinux login context.
(Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [main] (0x0020):
selinux_child failed!
(Thu Jul 14 10:37:14 2016) [[sssd[selinux_child[5585 [main] (0x0400):
selinux_child started.
(Thu Jul 14 10:37:14 2016) [[sssd[selinux_child[5585 [main] (0x0400):
context initialized
(Thu Jul 14 10:37:14 2016) [[sssd[selinux_child[5585 [main] (0x0400):
performing selinux operations
(Thu Jul 14 10:37:14 2016) [[sssd[selinux_child[5585 [libsemanage]
(0x0020): expected character ':', but found 'j'
(/etc/selinux/targeted/modules/active//seusers.final: 10):
ellul ja...@petermac.org.au:unconfined_u:s0-s0:c0.c1023
(Thu Jul 14 10:37:14 2016) [[sssd[selinux_child[5585 [libsemanage]
(0x0020): could not parse seuser record
(Thu Jul 14 10:37:14 2016) [[sssd[selinux_child[5585 [libsemanage]
(0x0020): could not cache file database
(Thu Jul 14 10:37:14 2016) [[sssd[selinux_child[5585 [libsemanage]
(0x0020): could not enter read-only section
(Thu Jul 14 10:37:14 2016) [[sssd[selinux_child[5585 [get_seuser]
(0x0020): Cannot query for madhamshettiwar p...@petermac.org.au
(Thu Jul 14 10:37:14 2016) [[sssd[selinux_child[5585 [libsemanage]
(0x0020): expected character ':', but found 'j'
(/etc/selinux/targeted/modules/tmp//seusers.final: 10):



We have SELinux disabled on all of our servers, but we hadn't disabled this
check in sssd.conf. So we enabled it in sssd.conf and everything worked
fine.

But it should be noted that this check seems to be failing on a space in
the AD user names.

(I know, spaces in user names is weird, wrong and embarrassing, but it's
not my department. A fantastic example of Technical Debt and why project
planning and testing are best done before implementation.)

cheers
L.
--
The most dangerous 

Re: [Freeipa-users] HBAC and AD users

[Lachlan Musicman]

On 14 July 2016 at 17:44, Sumit Bose  wrote:

> On Thu, Jul 14, 2016 at 11:47:41AM +1000, Lachlan Musicman wrote:
> > Ok, I have some logs of sssd 1.13.0 not working. Same values as before:
> >
> > FreeIPA server: Centos 7, ipa 4.2, API_VERSION 2.156
> >
> > Installed Packages
> > Name: ipa-server
> > Arch: x86_64
> > Version : 4.2.0
> > Release : 15.0.1.el7.centos.17
> > Size: 5.0 M
> > Repo: installed
> > >From repo   : updates
> > Summary : The IPA authentication server
> >
> >
> > Successfully joined in one way trust to AD.
> >
> > Successfully have added hosts (Centos 7, sssd 1.13.0).
> >
> >
> > [root@vmpr-linuxidm ~]# ipa hbacrule-find
> > 
> > 5 HBAC rules matched
> > 
> >
> >   Rule name: allow_all
> >   User category: all
> >   Host category: all
> >   Service category: all
> >   Description: Allow all users to access any host from any host
> >   Enabled: FALSE
> >
> > ...
> >
> >   Rule name: ssh to galaxy
> >   Service category: all
> >   Description: Allows ssh to galaxy server
> >   Enabled: TRUE
> >   User Groups: ad_users
> >   Hosts: papr-res-galaxy.unix.petermac.org.au
> >
> >
> >
> >
> > With allow_all HBAC rule enabled, can login every time with
> >
> > ssh user@ad_domain@unix_host
> >
> > If I implement a HBAC rule "ssh to galaxy" as per above, with:
> >
> > ad_users is a POSIX group with a GID. It has one member, the group
> >
> > ad_external an external group with a single, external, member
> >
> > pmc-res-ipaus...@petermac.org.au
> >
> > which is an AD group containing all the users that should have access to
> > the host.
> >
> >
> > With allow_all disabled and "ssh to galaxy" enabled, some users can login
> > and some can't. There is no discernable pattern that might explain why
> some
> > are discriminated against.
> >
> > Here is the test from the server:
> >
> > [root@vmpr-linuxidm ~]# ipa hbactest --user=sandsjor...@petermac.org.au
> > --host=papr-res-galaxy.unix.petermac.org.au --service=sshd
> > 
> > Access granted: True
> > 
> >   Matched rules: ssh to galaxy
> >   Not matched rules: Computing Cluster
> >   Not matched rules: FACS Computing
> >
> > I've installed ipa-admintools on the host in question and got the same
> > result.
> >
> > To be on the safe side/tick all boxes, I have cleared the cache on the
> host
> > in question:
> >
> > systemctl stop sssd
> > sss_cache -E
> > systemctl start sssd
> >
> > and confirmed success with a status check.
> >
> > When the user tries to login, it fails.
> >
> > Log is here:
> >
> > http://dpaste.com/0VAFNPH
> >
> >
> > The top is where the negotiating starts to the best of my knowledge.
> >
> > The attempts fails, with no information that is useful to me:
> >
> > 230 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
> > [hbac_get_category] (0x0200): Category is set to 'all'.
> > 231 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
> > [hbac_thost_attrs_to_rule] (0x1000): Processing target hosts for rule
> [ssh
> > to galaxy]
> > 232 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
> > [hbac_shost_attrs_to_rule] (0x0400): Processing source hosts for rule
> [ssh
> > to galaxy]
> > 233 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
> > [hbac_eval_user_element] (0x1000): [3] groups for [
> > sandsjor...@petermac.org.au]
>
> According to the HBAC evaluation the user is a member of 3 groups. Is
> this the expected number?
>
> Can you check if 'id sandsjor...@petermac.org.au' returns the expected
> list of groups on the client and the IPA server? (The client does not
> talk to AD directly only to the IPA server, so if something is already
> missing on the server it cannot be seen on the client as well).
>
>
No, this is incorrect. He belongs to 14 groups on both the FreeIPA server
and the host in question.

[root@vmpr-linuxidm ~]# id sandsjor...@petermac.org.au | tr "," "\n" | wc -l
14

[root@papr-res-galaxy ~]# id sandsjor...@petermac.org.au | tr "," "\n" | wc
-l
14



> Can you send me the SSSD cache file from the client
> /var/lib/sss/db/cache_unix.petermac.org.au.ldb after the login attempt?
> Since it might contain password hashes you might want to remove
> lines with 'cachedPassword' before
>
>

Ok, off list.



> bye,
> Sumit
>
>
-- 
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] IPA HBAC access using SSSD for user in trusted AD domain (RHEL 6.8)

[Sullivan, Daniel [AAA]]

Hi,

I wanted to follow up on this thread in case others are experiencing this 
problem.  Installing SSSD 1.14 from the copr repository seems to have 
completely eliminated the HBAC issue on all systems that were exhibiting the 
problem as previously described.

https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-14/

Also, FWIW thank you for fixing this (unrelated):

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

Thank you to everybody who helped with this.

Dan




This e-mail is intended only for the use of the individual or entity to which
it is addressed and may contain information that is privileged and confidential.
If the reader of this e-mail message is not the intended recipient, you are 
hereby notified that any dissemination, distribution or copying of this
communication is prohibited. If you have received this e-mail in error, please 
notify the sender and destroy all copies of the transmittal. 

Thank you
University of Chicago Medicine and Biological Sciences 


-- 
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] IPA HBAC access using SSSD for user in trusted AD domain (RHEL 6.8)

[Justin Stephenson]

Hello Daniel,

Just to clarify the issue:

user 'a.cri.dsulli...@bsdad.uchicago.edu' is a member of IDM POSIX group 
'cri-cri_server_administrators_ipa' which is linked to the external 
group used for the AD trust.


The following HBAC rule is not working to allow SSH access

[root@cri-ksysipadcp2 a.cri.dsullivan]# ipa hbacrule-show 
'cri-cri_server_administrators_allow_all'

  Rule name: cri-cri_server_administrators_allow_all
  Host category: all
  Service category: all
  Description: Allow anyone in 
cri-cri_server_administrat...@bsdad.uchicago.edu 
to login to any machine

  Enabled: TRUE
  User Groups: cri-cri_server_administrators_ipa

==

During the HBAC processing, sssd checks which groups are associated with 
the HBAC rule and adds those groups(just the 
'cri-cri_server_administrators_ipa' group in this case) to the 
memberUser attribute of the HBAC rule sysdb entry.


(Wed Jul 13 12:07:13 2016) [sssd[be[ipa.cri.uchicago.edu]]] 
[hbac_attrs_to_rule] (0x1000): Processing rule 
[cri-cri_server_administrators_allow_all]
(Wed Jul 13 12:07:13 2016) [sssd[be[ipa.cri.uchicago.edu]]] 
[sysdb_search_groups] (0x2000): Search groups with filter: 
(&(objectclass=group)(originalDN=cn=cri-cri_server_administrators_ipa,cn=groups,cn=accounts,dc=ipa,dc=cri,dc=uchicago,dc=edu))
(Wed Jul 13 12:07:13 2016) [sssd[be[ipa.cri.uchicago.edu]]] 
[hbac_user_attrs_to_rule] (0x2000): Added POSIX group 
[cri-cri_server_administrators_ipa] to rule 
[cri-cri_server_administrators_allow_all]


The hbac evaluation reads the originalMemberof attribute of 
'a.cri.dsulli...@bsdad.uchicago.edu' to assess the groups which HBAC 
should match with


(Wed Jul 13 12:07:13 2016) [sssd[be[ipa.cri.uchicago.edu]]] 
[hbac_eval_user_element] (0x1000): [30] groups for 
[a.cri.dsulli...@bsdad.uchicago.edu]


With debug logging enabled we should see a message such as the following 
when the group is found, but we don't see that in your log output:


[hbac_eval_user_element]  Added group 
[cri-cri_server_administrators_ipa] for user 
[a.cri.dsulli...@bsdad.uchicago.edu]


We need to understand why this group is being removed from the sysdb, as 
you said the group does not return in id command output after the SSH 
attempt.


It would be great to get full sssd debug logs and a dump of the sssd 
sysdb cache after the first 'id' command is run, and then after the SSH 
attempt is made when the group no longer shows. Note the ldbsearch 
command is included in the 'ldb-tools' rpm


For example:

  ldbsearch -H /var/lib/sss/db/cache_.ldb > 
ldbsearch-first-id-command.ldb


  ldbsearch -H /var/lib/sss/db/cache_.ldb > 
ldbsearch-after-ssh-attempt.ldb


Kind regards,
Justin Stephenson


On 07/13/2016 03:14 PM, Sullivan, Daniel [AAA] wrote:

Jakub, Justin,

Thank you both very much for taking the time to continue helping me resolve 
this issue.  I apologize for not replying right away; I’ve been dealing with a 
production issue for most of the morning.

An invocation of ‘id 
a.cri.dsulli...@bsdad.uchicago.edu’ on the IPA DC 
shows me as a member of the POSIX IPA group 
(cri_server_administrators_...@ipa.cri.uchicago.edu)
 as well as the AD domain group in the trusted domain 
(cri-aaa_server_administrat...@bsdad.uchicago.edu).
  This remains consistent across any number of successful sshd logins into the DC using my 
a.cri.dsullivan@bsdad.uchicago.edu account, including 
after clearing the cache on the DC.

On the client, I am seeing some unusual behavior.  If I run the commands 'sss_cache -E; 
service sssd stop ; rm -rf /var/log/sssd/* ; service sssd start’ , then run ‘id 
a.cri.dsulli...@bsdad.uchicago.edu’, I see 
the POSIX IPA group as well as the AD domain group as described above (what I presumably 
want and expect).  However (and this is the unusual part), if I attempt to login via SSH 
(it will fail with HBAC validation), and then run the ‘id 
a.cri.dsulli...@bsdad.uchicago.edu’ 
command again , the POSIX IPA group disappears from the list of groups output by the id 
command.  From what I can tell, this group will not reappear in the group list on the 
client until the client cache is cleared.  Presumably this behavior is related to the HBAC 
authentication errors I am experiencing.  I have cleared the cache on both the DC and the 
client using ssh_cache -E and this behavior is still exhibited.  With respect to output 
from testing:

1) The sssd domain log from from the client of the initial id invocation (both groups 
appear) after clearing the cache (on the client) can be found here (this output 
contains both 

Re: [Freeipa-users] FreeIPA (Add Replica fails on GSSAPI)

[Devin Acosta]

When i tried to create the replica from another server, it fails giving me
this?

[root@ipa02-aws ~]# ipa-replica-prepare ipa03-aws.rsinc.local --ip-address
10.40.x.x
Directory Manager (existing master) password:

If you installed IPA with your own certificates using PKCS#12 files you
must provide PKCS#12 files for any replicas you create as well.
The replica must be created on the primary IPA server.

On Thu, Jul 14, 2016 at 8:22 AM, Petr Vobornik  wrote:

> On 07/14/2016 07:18 AM, Bjarne Blichfeldt wrote:
> > Well, I just had the same problem, but in my case I also tried to
> install a ca:
> >
> > “ipa-replica-install --setup-ca …..”
> >
> > Without “--set-up”  the installation succeeded.
> >
> > Regards,
> >
> > Bjarne
> >
>
> The error below is not related to CA.
>
> It tries to check that new replica's ldap service principal was replica
> to master server. The principal is not replicated there and after 60
> attemps it fails.
>
> What is your replication topology? Could it be that other replicas are
> keeping this master busy?
>
> Does installation against other replica work?
>
> Could you provide dirsrv error log of the master from the time of
> installation?
>
> >
> >
> > *From:*Devin Acosta [mailto:linuxguru...@gmail.com]
> > *Sent:* 12. juli 2016 21:35
> > *To:* freeipa-users@redhat.com
> > *Subject:* [Freeipa-users] FreeIPA (Add Replica fails on GSSAPI)
> >
> > I am trying to add a 4th replica to my FreeIPA installation. I am
> running the
> > latest CentOS 7.2 (full updates) and i have tried multiple times and
> fails every
> > time in same location. When it fails I remove the replication agreements
> and try
> > again and keeps failing in same location.
> >
> > [root@ipa03-aws centos]# ipa-replica-install
> replica-info-ipa03-aws.rsinc.local.gpg
> >
> > WARNING: conflicting time synchronization service 'chronyd' will
> >
> > be disabled in favor of ntpd
> >
> > Directory Manager (existing master) password:
> >
> > Run connection check to master
> >
> > Check connection from replica to remote master 'ipa01-aws.rsinc.local':
> >
> > Directory Service: Unsecure port (389): OK
> >
> > Directory Service: Secure port (636): OK
> >
> > Kerberos KDC: TCP (88): OK
> >
> > Kerberos Kpasswd: TCP (464): OK
> >
> > HTTP Server: Unsecure port (80): OK
> >
> > HTTP Server: Secure port (443): OK
> >
> > The following list of ports use UDP protocol and would need to be
> >
> > checked manually:
> >
> > Kerberos KDC: UDP (88): SKIPPED
> >
> > Kerberos Kpasswd: UDP (464): SKIPPED
> >
> > Connection from replica to master is OK.
> >
> > Start listening on required ports for remote master check
> >
> > Get credentials to log in to remote master
> >
> > admin@RSINC.LOCAL  password:
> >
> > Check SSH connection to remote master
> >
> > Execute check on remote master
> >
> > Check connection from master to remote replica 'ipa03-aws.rsinc.local':
> >
> > Directory Service: Unsecure port (389): OK
> >
> > Directory Service: Secure port (636): OK
> >
> > Kerberos KDC: TCP (88): OK
> >
> > Kerberos KDC: UDP (88): OK
> >
> > Kerberos Kpasswd: TCP (464): OK
> >
> > Kerberos Kpasswd: UDP (464): OK
> >
> > HTTP Server: Unsecure port (80): OK
> >
> > HTTP Server: Secure port (443): OK
> >
> > Connection from master to replica is OK.
> >
> > Connection check OK
> >
> > Configuring NTP daemon (ntpd)
> >
> >[1/4]: stopping ntpd
> >
> >[2/4]: writing configuration
> >
> >[3/4]: configuring ntpd to start on boot
> >
> >[4/4]: starting ntpd
> >
> > Done configuring NTP daemon (ntpd).
> >
> > Configuring directory server (dirsrv). Estimated time: 1 minute
> >
> >[1/38]: creating directory server user
> >
> >[2/38]: creating directory server instance
> >
> >[3/38]: adding default schema
> >
> >[4/38]: enabling memberof plugin
> >
> >[5/38]: enabling winsync plugin
> >
> >[6/38]: configuring replication version plugin
> >
> >[7/38]: enabling IPA enrollment plugin
> >
> >[8/38]: enabling ldapi
> >
> >[9/38]: configuring uniqueness plugin
> >
> >[10/38]: configuring uuid plugin
> >
> >[11/38]: configuring modrdn plugin
> >
> >[12/38]: configuring DNS plugin
> >
> >[13/38]: enabling entryUSN plugin
> >
> >[14/38]: configuring lockout plugin
> >
> >[15/38]: creating indices
> >
> >[16/38]: enabling referential integrity plugin
> >
> >[17/38]: configuring ssl for ds instance
> >
> >[18/38]: configuring certmap.conf
> >
> >[19/38]: configure autobind for root
> >
> >[20/38]: configure new location for managed entries
> >
> >[21/38]: configure dirsrv ccache
> >
> >[22/38]: enable SASL mapping fallback
> >
> >[23/38]: restarting directory server
> >
> >[24/38]: setting up initial replication
> >
> > Starting replication, please wait until this has completed.
> >
> > Update in progress, 4 seconds elapsed
> >
> > Update 

Re: [Freeipa-users] sudo - differences between Centos 6.5 and Centos 7.0?

[Lukas Slebodnik]

On (14/07/16 13:52), Tomas Simecek wrote:
>Hi Lukas,
>sorry to say, but nothing helps.
>
>I have just updated IPA server, so that now it is:
>[root@svlxxipap ~]# cat /etc/redhat-release
>CentOS Linux release 7.2.1511 (Core)
>
>with:
>[root@svlxxipap ~]# rpm -qa|grep ipa
>ipa-server-trust-ad-4.2.0-15.0.1.el7.centos.17.x86_64
>libipa_hbac-1.13.0-40.el7_2.9.x86_64
>ipa-python-4.2.0-15.0.1.el7.centos.17.x86_64
>ipa-server-dns-4.2.0-15.0.1.el7.centos.17.x86_64
>python-iniparse-0.4-9.el7.noarch
>ipa-server-4.2.0-15.0.1.el7.centos.17.x86_64
>sssd-ipa-1.13.0-40.el7_2.9.x86_64
>ipa-admintools-4.2.0-15.0.1.el7.centos.17.x86_64
>python-libipa_hbac-1.13.0-40.el7_2.9.x86_64
>ipa-client-4.2.0-15.0.1.el7.centos.17.x86_64
>
It has to work with IPA on CentOS 7.2
and sssd-1.13.3-22.el6_8.4 on client.

>I have also changed sudoers to sudo in sssd.conf as you suggested and
>restarted sssd.
>No difference, still:
>[simecek.to...@sd-stc.cz@zp-cml-test ~]$ sudo service sshd restart
>[sudo] password for simecek.to...@sd-stc.cz:
>simecek.to...@sd-stc.cz is not in the sudoers file.  This incident will be
>reported.
>
>I guess I will pilot some more IPA clients to make sure it works reliably
>and if yes, I guess we will be able to live with the fact that older
>Linuxes doe not offer sudo to AD clients.
>
I assume you meant AD users from trust.

But previously, you provided data and user was member of group which
should be alowed to use sudo rules.

I would like to find out why sudo rules were not fetched from IPA.

I would like to see full log file + dump of sssd cache.
Please:
* clean cache and log files on *IPA server*
  rm -f /var/lib/sss/db/* /var/log/sssd/*
* enable debug_level=9 in domain section and sudo
* restart sssd on *IPA server*

* clean cache and log files on *IPA client*
  rm -f /var/lib/sss/db/* /var/log/sssd/*
* enable debug_level=9 in domain section and sudo
* restart sssd *IPA client*


* authernticate with user simecek.to...@sd-stc.cz
* call id simecek.to...@sd-stc.cz
* try sudo.

* send all sssd log files + sssd.conf
* provide dump of sssd cache
  ldbsearch -H /var/lib/sss/db/cache_$domain.ldb
(utility ldbsearch is part of package ldb-tools


Please provide log files, sssd.conf and dump of sssd cache
from client and also from IPA server.

Thank you very much for patience.

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] Replication Agreement issues noticed with repl-monitor.pl

[Devin Acosta]

ipa01-jap was a host that is no more, is there a simple way to clear these
replication agreements to clean it up?

On Thu, Jul 14, 2016 at 7:14 AM, Petr Vobornik  wrote:

> On 07/14/2016 12:57 PM, Martin Kosek wrote:
> > On 07/13/2016 04:24 AM, Devin Acosta wrote:
> >>
> >> I was trying to create another Replica but then noticed it was
> constantly having
> >> issues trying to finish the joining of the replication. I then ran the
> command:
> >> repl-monitor.pl , It appears i have several
> replicaid's
> >> and they seem to be having issues, wondering if this is adding to my
> issue.
> >>
> >> Anyone know how I can resolve this issue and clean up the replication???
> >>
> >> See attached Screenshot.
> >
> > I wonder if cleaning RUVs help:
> >
> >
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/trouble-replica.html#trouble-repl-cleanruv
> >
>
> dangling RUVs
>
> 1. "Can't acquire busy replica"
> seems OK if it disappears after a while.
>
> 2. "1 Unable to acquire replicaLDAP error: Can't contact LDAP"
> Probably worth investigating if ipa01-
> i2x.rsinc.local:389 and ipa01-
> jap.rsinc.local:389 still exist. If not then there is probably a
> dangling replication agreement for o=ipaca suffix.
>
> --
> 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

Re: [Freeipa-users] FreeIPA (Add Replica fails on GSSAPI)

[Petr Vobornik]

On 07/14/2016 07:18 AM, Bjarne Blichfeldt wrote:
> Well, I just had the same problem, but in my case I also tried to install a 
> ca:
> 
> “ipa-replica-install --setup-ca …..”
> 
> Without “--set-up”  the installation succeeded.
> 
> Regards,
> 
> Bjarne
> 

The error below is not related to CA.

It tries to check that new replica's ldap service principal was replica
to master server. The principal is not replicated there and after 60
attemps it fails.

What is your replication topology? Could it be that other replicas are
keeping this master busy?

Does installation against other replica work?

Could you provide dirsrv error log of the master from the time of
installation?

>   
> 
> *From:*Devin Acosta [mailto:linuxguru...@gmail.com]
> *Sent:* 12. juli 2016 21:35
> *To:* freeipa-users@redhat.com
> *Subject:* [Freeipa-users] FreeIPA (Add Replica fails on GSSAPI)
> 
> I am trying to add a 4th replica to my FreeIPA installation. I am running the 
> latest CentOS 7.2 (full updates) and i have tried multiple times and fails 
> every 
> time in same location. When it fails I remove the replication agreements and 
> try 
> again and keeps failing in same location.
> 
> [root@ipa03-aws centos]# ipa-replica-install 
> replica-info-ipa03-aws.rsinc.local.gpg
> 
> WARNING: conflicting time synchronization service 'chronyd' will
> 
> be disabled in favor of ntpd
> 
> Directory Manager (existing master) password:
> 
> Run connection check to master
> 
> Check connection from replica to remote master 'ipa01-aws.rsinc.local':
> 
> Directory Service: Unsecure port (389): OK
> 
> Directory Service: Secure port (636): OK
> 
> Kerberos KDC: TCP (88): OK
> 
> Kerberos Kpasswd: TCP (464): OK
> 
> HTTP Server: Unsecure port (80): OK
> 
> HTTP Server: Secure port (443): OK
> 
> The following list of ports use UDP protocol and would need to be
> 
> checked manually:
> 
> Kerberos KDC: UDP (88): SKIPPED
> 
> Kerberos Kpasswd: UDP (464): SKIPPED
> 
> Connection from replica to master is OK.
> 
> Start listening on required ports for remote master check
> 
> Get credentials to log in to remote master
> 
> admin@RSINC.LOCAL  password:
> 
> Check SSH connection to remote master
> 
> Execute check on remote master
> 
> Check connection from master to remote replica 'ipa03-aws.rsinc.local':
> 
> Directory Service: Unsecure port (389): OK
> 
> Directory Service: Secure port (636): OK
> 
> Kerberos KDC: TCP (88): OK
> 
> Kerberos KDC: UDP (88): OK
> 
> Kerberos Kpasswd: TCP (464): OK
> 
> Kerberos Kpasswd: UDP (464): OK
> 
> HTTP Server: Unsecure port (80): OK
> 
> HTTP Server: Secure port (443): OK
> 
> Connection from master to replica is OK.
> 
> Connection check OK
> 
> Configuring NTP daemon (ntpd)
> 
>[1/4]: stopping ntpd
> 
>[2/4]: writing configuration
> 
>[3/4]: configuring ntpd to start on boot
> 
>[4/4]: starting ntpd
> 
> Done configuring NTP daemon (ntpd).
> 
> Configuring directory server (dirsrv). Estimated time: 1 minute
> 
>[1/38]: creating directory server user
> 
>[2/38]: creating directory server instance
> 
>[3/38]: adding default schema
> 
>[4/38]: enabling memberof plugin
> 
>[5/38]: enabling winsync plugin
> 
>[6/38]: configuring replication version plugin
> 
>[7/38]: enabling IPA enrollment plugin
> 
>[8/38]: enabling ldapi
> 
>[9/38]: configuring uniqueness plugin
> 
>[10/38]: configuring uuid plugin
> 
>[11/38]: configuring modrdn plugin
> 
>[12/38]: configuring DNS plugin
> 
>[13/38]: enabling entryUSN plugin
> 
>[14/38]: configuring lockout plugin
> 
>[15/38]: creating indices
> 
>[16/38]: enabling referential integrity plugin
> 
>[17/38]: configuring ssl for ds instance
> 
>[18/38]: configuring certmap.conf
> 
>[19/38]: configure autobind for root
> 
>[20/38]: configure new location for managed entries
> 
>[21/38]: configure dirsrv ccache
> 
>[22/38]: enable SASL mapping fallback
> 
>[23/38]: restarting directory server
> 
>[24/38]: setting up initial replication
> 
> Starting replication, please wait until this has completed.
> 
> Update in progress, 4 seconds elapsed
> 
> Update succeeded
> 
>[25/38]: updating schema
> 
>[26/38]: setting Auto Member configuration
> 
>[27/38]: enabling S4U2Proxy delegation
> 
>[28/38]: importing CA certificates from LDAP
> 
>[29/38]: initializing group membership
> 
>[30/38]: adding master entry
> 
>[31/38]: initializing domain level
> 
>[32/38]: configuring Posix uid/gid generation
> 
>[33/38]: adding replication acis
> 
>[34/38]: enabling compatibility plugin
> 
>[35/38]: activating sidgen plugin
> 
>[36/38]: activating extdom plugin
> 
>[37/38]: tuning directory server
> 
>[38/38]: configuring directory to start on boot
> 
> Done configuring directory server 

Re: [Freeipa-users] named-pkcs11 fails on new ipa replica

[Petr Vobornik]

On 07/13/2016 08:51 PM, Bob Hinton wrote:
> Hi,
> 
> We are trying to create a new replica on RHEL 7.2
> 
> This completes but named-pkcs11 fails to start -
> 
>  systemctl status named-pkcs11.service
> ● named-pkcs11.service - Berkeley Internet Name Domain (DNS) with native
> PKCS#11
>Loaded: loaded (/usr/lib/systemd/system/named-pkcs11.service;
> disabled; vendor preset: disabled)
>Active: failed (Result: exit-code) since Wed 2016-07-13 18:38:15 BST;
> 51min ago
>   Process: 25913 ExecStart=/usr/sbin/named-pkcs11 -u named $OPTIONS
> (code=exited, status=1/FAILURE)
>   Process: 25910 ExecStartPre=/bin/bash -c if [ !
> "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -z
> /etc/named.conf; else echo "Checking of zone files is disabled"; fi
> (code=exited, status=0/SUCCESS)
> 
> Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]: corporation. 
> Support and training for BIND 9 are
> Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]: available at
> https://www.isc.org/support
> Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]:
> 
> Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]: adjusted limit on
> open files from 4096 to 1048576
> Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]: found 1 CPU,
> using 1 worker thread
> Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]: using 1 UDP
> listener per interface
> Jul 13 18:38:15 ipa001.mgmt.local systemd[1]: named-pkcs11.service:
> control process exited, code=exited status=1
> Jul 13 18:38:15 ipa001.mgmt.local systemd[1]: Failed to start Berkeley
> Internet Name Domain (DNS) with native PKCS#11.
> Jul 13 18:38:15 ipa001.mgmt.local systemd[1]: Unit named-pkcs11.service
> entered failed state.
> Jul 13 18:38:15 ipa001.mgmt.local systemd[1]: named-pkcs11.service failed.
> 
> # /usr/sbin/named-pkcs11 -d 9 -g
> 13-Jul-2016 19:31:01.283 starting BIND 9.9.4-RedHat-9.9.4-29.el7_2.1 -d 9 -g
> 13-Jul-2016 19:31:01.283 built with '--build=x86_64-redhat-linux-gnu'
> '--host=x86_64-redhat-linux-gnu' '--program-prefix='
> '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr'
> '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc'
> '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64'
> '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib'
> '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-libtool'
> '--localstatedir=/var' '--enable-threads' '--enable-ipv6'
> '--enable-filter-' '--enable-rrl' '--with-pic' '--disable-static'
> '--disable-openssl-version-check' '--enable-exportlib'
> '--with-export-libdir=/usr/lib64'
> '--with-export-includedir=/usr/include'
> '--includedir=/usr/include/bind9' '--enable-native-pkcs11'
> '--with-pkcs11=/usr/lib64/pkcs11/libsofthsm2.so' '--with-dlopen=yes'
> '--with-dlz-ldap=yes' '--with-dlz-postgres=yes' '--with-dlz-mysql=yes'
> '--with-dlz-filesystem=yes' '--with-dlz-bdb=yes' '--with-gssapi=yes'
> '--disable-isc-spnego' '--enable-fixed-rrset'
> '--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets'
> 'build_alias=x86_64-redhat-linux-gnu'
> 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall
> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
> --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic'
> 'LDFLAGS=-Wl,-z,relro ' 'CPPFLAGS= -DDIG_SIGCHASE'
> 13-Jul-2016 19:31:01.283
> 
> 13-Jul-2016 19:31:01.284 BIND 9 is maintained by Internet Systems
> Consortium,
> 13-Jul-2016 19:31:01.284 Inc. (ISC), a non-profit 501(c)(3) public-benefit
> 13-Jul-2016 19:31:01.284 corporation.  Support and training for BIND 9 are
> 13-Jul-2016 19:31:01.284 available at https://www.isc.org/support
> 13-Jul-2016 19:31:01.284
> 
> 13-Jul-2016 19:31:01.284 adjusted limit on open files from 4096 to 1048576
> 13-Jul-2016 19:31:01.284 found 1 CPU, using 1 worker thread
> 13-Jul-2016 19:31:01.284 using 1 UDP listener per interface
> 13-Jul-2016 19:31:01.284 using up to 4096 sockets
> 13-Jul-2016 19:31:01.284 Registering DLZ_dlopen driver
> 13-Jul-2016 19:31:01.284 Registering SDLZ driver 'dlopen'
> 13-Jul-2016 19:31:01.284 Registering DLZ driver 'dlopen'
> 13-Jul-2016 19:31:01.287 initializing DST: PKCS#11 initialization failed
> 13-Jul-2016 19:31:01.287 exiting (due to fatal error)
> 
> # tail -2 /var/log
> 
> Jul 13 19:31:01 ipa001.mgmt.local named-pkcs11[27088]:
> ObjectStore.cpp(59): Failed to enumerate object store in
> /var/lib/softhsm/tokens/
> 
> Jul 13 19:31:01 ipa001.mgmt.local named-pkcs11[27088]: SoftHSM.cpp(456):
> Could not load the object store
> 
> I've tried "ipa-server-upgrade" and
> 
> mv /var/lib/ipa/dnssec/tokens /var/lib/ipa/dnssec/tokens-OLD
> 
> ipa-dns-install
> 
> But I haven't managed to fix it.
> 
> Using "ipactl start -f" means the rest of the ipa services seem to work
> properly, but without named.
> 
> Is there a way to fix the 

Re: [Freeipa-users] Migrating to FreeIPA from an existing Heimdal Kerberos and 389-ds deployment

[Petr Vobornik]

On 07/14/2016 07:13 AM, Grant Wu wrote:
> Hi all,
> 
> I'm part of the CMU Computer Club and our Kerberos/LDAP deployment has been a 
> pain point for quite some time.  I've heard that FreeIPA might be a solution 
> worth exploring.
> 
> I would like to try to avoid user visible disruption if possible, however.  
> This 
> means that we would like to keep our Kerberos realm name, keep AFS 
> cross-realm 
> authentication working, etc.  UIDs remaining the same would be good; I'd have 
> to 
> think about

Users and groups can be migrated by
 `ipa migrate-ds` command.
It allows you to keep UIDs and GIDs but one must make sure that IPA
servers are configured to issue new UIDs and GIDs which doesn't overlap
with the migrated ones. There are options in ipa-server-install and
ipa-replica-manage tools for that.

This can be evaluated in an isolated network against a clone of your
LDAP server.

Cross realm trust with AFS is a challenge though. IPA now supports only
cross realm trust with Active Directory. Trusts with other general KDCs
are not yet supported.

Other migration challenge might be migration of services. It is not done
by the above mentioned `ipa migrate-ds`. When the service accounts are
added to IPA, you would have to obtain new keytabs for the services.

> 
> Essentially all of our clients are various flavors of Debian; mostly Jessie 
> (we 
> have an unfortunate number of older machines that I hope to upgrade soon).

A possibility is to use SSSD as client on Debian.

> 
> Has anyone done something like this before?  Anyone have any ideas what the 
> migration path would look like or whether this is even possible?
> 
> Thanks,
> 
> Grant Wu
> gran...@andrew.cmu.edu 
> 
-- 
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

Re: [Freeipa-users] Freeipa replication issue

[Mark Reynolds]

On 07/14/2016 10:10 AM, Stefan Uygur wrote:
> Hi Alexander,
> Thanks for a quick reply first of all and to be honest actually I have tried 
> that link too, it didn't work either.
>
> This is my ipa version: ipa-server-3.0.0-47.el6_7.2.x86_64 and the system is 
> RHEL 6
>
> When I reproduce the last step of the instructions you provided:
>
> ldappasswd -h localhost -ZZ -p 389 -x -D "cn=Directory Manager" -W -T 
> dm_password
> Enter LDAP Password:
> ldap_bind: Invalid credentials (49)
>
> Or trying this one (because I am not sure if I have dogtag 10):
>
> ldappasswd -h localhost -ZZ -p 7389 -x -D "cn=Directory Manager" -W -T 
> dm_password
> Enter LDAP Password:
> Result: No such object (32)
> Additional info: No such Entry exists.
The problem here is that "cn=directory manager" does not exist in a
database.  It only exists in the cn=config entry, so ldappasswd will not
work.  You must follow this process:

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/dirmnger-pwd.html#dirmnger-pwd-Resetting_Passwords

But I'm not sure if your problem is the directory manager account
though.  You need to look through the Directory Server access log for
"err=49" (/var/log/dirsrv/slapd-INSTANCE/access), and see which BIND dn
is failing.  It could be a different user/account.

Mark
>
> I couldn't figure out clearly, your help much appreciated wherever you can.
>
> Many thanks
>
>
> -Original Message-
> From: Alexander Bokovoy [mailto:aboko...@redhat.com] 
> Sent: 14 July 2016 14:39
> To: Stefan Uygur
> Cc: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] Freeipa replication issue
>
> On Thu, 14 Jul 2016, Stefan Uygur wrote:
>> Hi All,
>> Sorry if this would appear to be an obvious issue and maybe someone has 
>> already discussed about it but I couldn't get anywhere information 
>> about how to resolve this issue that I am experiencing.
>>
>> Basically I have an IPA master server where the admin password was 
>> originally the same as Directory Manager password, within months the 
>> admin password was changed and DM left as it was.
>>
>> But I have followed the instructions given in below link to reset DM
>> password:
>>
>> https://www.centos.org/docs/5/html/CDS/install/8.0/Installation_Guide-C
>> ommon_Usage-Resetting_Passwords.html
> This is incorrect document as it is not relevant to IPA.
>
> Use http://www.freeipa.org/page/Howto/Change_Directory_Manager_Password
>
>> Which I have tested after the reset using ldapsearch and it seems to be 
>> working perfectly.
>>
>> But when I try to prepare the replica it keep telling me that is wrong 
>> password as per below:
>>
>> ipa-replica-prepare ipa2.example.com --ip-address 10.0.0.3 Directory 
>> Manager (existing master) password:
>> The password provided is incorrect for LDAP server ipa1.example.com
>>
>>
>> Usint the following to test the DM password:
>>
>> ldapsearch -x -D "cn=directory manager" -w DM_PASSWD base -b "" 
>> "objectclass=*"
>>
>> Which gives me the correct result, long output.but again, when I 
>> try to prepare replica still getting wrong password.
> There are more places where DM password is used for replica. You changed it 
> only 389-ds but didn't change other places. Use instructions above.
>
>
> --
> / Alexander Bokovoy
>

-- 
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] Replication Agreement issues noticed with repl-monitor.pl

[Petr Vobornik]

On 07/14/2016 12:57 PM, Martin Kosek wrote:
> On 07/13/2016 04:24 AM, Devin Acosta wrote:
>>
>> I was trying to create another Replica but then noticed it was constantly 
>> having 
>> issues trying to finish the joining of the replication. I then ran the 
>> command: 
>> repl-monitor.pl , It appears i have several 
>> replicaid's 
>> and they seem to be having issues, wondering if this is adding to my issue.
>>
>> Anyone know how I can resolve this issue and clean up the replication???
>>
>> See attached Screenshot.
> 
> I wonder if cleaning RUVs help:
> 
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/trouble-replica.html#trouble-repl-cleanruv
> 

dangling RUVs

1. "Can't acquire busy replica"
seems OK if it disappears after a while.

2. "1 Unable to acquire replicaLDAP error: Can't contact LDAP"
Probably worth investigating if ipa01-
i2x.rsinc.local:389 and ipa01-
jap.rsinc.local:389 still exist. If not then there is probably a
dangling replication agreement for o=ipaca suffix.

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

Re: [Freeipa-users] Freeipa replication issue

[Stefan Uygur]

Hi Alexander,
Thanks for a quick reply first of all and to be honest actually I have tried 
that link too, it didn't work either.

This is my ipa version: ipa-server-3.0.0-47.el6_7.2.x86_64 and the system is 
RHEL 6

When I reproduce the last step of the instructions you provided:

ldappasswd -h localhost -ZZ -p 389 -x -D "cn=Directory Manager" -W -T 
dm_password
Enter LDAP Password:
ldap_bind: Invalid credentials (49)

Or trying this one (because I am not sure if I have dogtag 10):

ldappasswd -h localhost -ZZ -p 7389 -x -D "cn=Directory Manager" -W -T 
dm_password
Enter LDAP Password:
Result: No such object (32)
Additional info: No such Entry exists.

I couldn't figure out clearly, your help much appreciated wherever you can.

Many thanks


-Original Message-
From: Alexander Bokovoy [mailto:aboko...@redhat.com] 
Sent: 14 July 2016 14:39
To: Stefan Uygur
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Freeipa replication issue

On Thu, 14 Jul 2016, Stefan Uygur wrote:
>Hi All,
>Sorry if this would appear to be an obvious issue and maybe someone has 
>already discussed about it but I couldn't get anywhere information 
>about how to resolve this issue that I am experiencing.
>
>Basically I have an IPA master server where the admin password was 
>originally the same as Directory Manager password, within months the 
>admin password was changed and DM left as it was.
>
>But I have followed the instructions given in below link to reset DM
>password:
>
>https://www.centos.org/docs/5/html/CDS/install/8.0/Installation_Guide-C
>ommon_Usage-Resetting_Passwords.html
This is incorrect document as it is not relevant to IPA.

Use http://www.freeipa.org/page/Howto/Change_Directory_Manager_Password

>Which I have tested after the reset using ldapsearch and it seems to be 
>working perfectly.
>
>But when I try to prepare the replica it keep telling me that is wrong 
>password as per below:
>
>ipa-replica-prepare ipa2.example.com --ip-address 10.0.0.3 Directory 
>Manager (existing master) password:
>The password provided is incorrect for LDAP server ipa1.example.com
>
>
>Usint the following to test the DM password:
>
>ldapsearch -x -D "cn=directory manager" -w DM_PASSWD base -b "" "objectclass=*"
>
>Which gives me the correct result, long output.but again, when I 
>try to prepare replica still getting wrong password.
There are more places where DM password is used for replica. You changed it 
only 389-ds but didn't change other places. Use instructions above.


--
/ Alexander Bokovoy

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

[Stefan Uygur]

Hi All,
Sorry if this would appear to be an obvious issue and maybe someone has already 
discussed about it but I couldn't get anywhere information about how to resolve 
this issue that I am experiencing.

Basically I have an IPA master server where the admin password was originally 
the same as Directory Manager password, within months the admin password was 
changed and DM left as it was.

But I have followed the instructions given in below link to reset DM password:

https://www.centos.org/docs/5/html/CDS/install/8.0/Installation_Guide-Common_Usage-Resetting_Passwords.html

Which I have tested after the reset using ldapsearch and it seems to be working 
perfectly.

But when I try to prepare the replica it keep telling me that is wrong password 
as per below:

ipa-replica-prepare ipa2.example.com --ip-address 10.0.0.3
Directory Manager (existing master) password:
The password provided is incorrect for LDAP server ipa1.example.com


Usint the following to test the DM password:

ldapsearch -x -D "cn=directory manager" -w DM_PASSWD base -b "" "objectclass=*"

Which gives me the correct result, long output.but again, when I try to 
prepare replica still getting wrong password.

Any help greatly appreciated.

Stefan

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

[Alexander Bokovoy]

On Thu, 14 Jul 2016, Stefan Uygur wrote:

Hi All,
Sorry if this would appear to be an obvious issue and maybe someone has
already discussed about it but I couldn't get anywhere information
about how to resolve this issue that I am experiencing.

Basically I have an IPA master server where the admin password was
originally the same as Directory Manager password, within months the
admin password was changed and DM left as it was.

But I have followed the instructions given in below link to reset DM
password:

https://www.centos.org/docs/5/html/CDS/install/8.0/Installation_Guide-Common_Usage-Resetting_Passwords.html

This is incorrect document as it is not relevant to IPA.

Use http://www.freeipa.org/page/Howto/Change_Directory_Manager_Password


Which I have tested after the reset using ldapsearch and it seems to be
working perfectly.

But when I try to prepare the replica it keep telling me that is wrong
password as per below:

ipa-replica-prepare ipa2.example.com --ip-address 10.0.0.3
Directory Manager (existing master) password:
The password provided is incorrect for LDAP server ipa1.example.com


Usint the following to test the DM password:

ldapsearch -x -D "cn=directory manager" -w DM_PASSWD base -b "" "objectclass=*"

Which gives me the correct result, long output.but again, when I
try to prepare replica still getting wrong password.

There are more places where DM password is used for replica. You changed
it only 389-ds but didn't change other places. Use instructions above.


--
/ Alexander Bokovoy

--
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] IPA HBAC access using SSSD for user in trusted AD domain (RHEL 6.8)

[Sullivan, Daniel [AAA]]

Hi,

I have a brief follow up question regarding this issue; 

I’m actually not bent on using HBAC; it is a nice feature and I’d like to use 
it, but at the end of the day I’m not married to the idea of managing this type 
of policy centrally; in theory, group or user based access control using 
AllowGroups/AllowUsers in sshd_config should work, as long as 
GSSAPIAuthentication and UsePAM are enabled, right? I’ve seen a couple of 
threads that suggest this is possible, although I haven’t seen it explicitly 
mentioned anywhere in the documentation.

I’ve made a brief failed attempt at getting sshd authentication working using 
AllowGroups in sshd_config, however I haven’t spent a whole lot of time on it 
yet (I’m running into some issues with PAM, presumably to pre-existing problems 
with group enumeration).

I’m growing concerned about our upcoming IPA implementation because as of now I 
don’t have a known workaround to the issue described in this thread (it is 
impacting more than one client).  Any advice with respect to a viable 
workaround to this issue would be appreciated.

Thank you so much for your ongoing support.

Best,

Dan

> On Jul 13, 2016, at 2:14 PM, Sullivan, Daniel [AAA] 
>  wrote:
> 
> Jakub, Justin,
> 
> Thank you both very much for taking the time to continue helping me resolve 
> this issue.  I apologize for not replying right away; I’ve been dealing with 
> a production issue for most of the morning.
> 
> An invocation of ‘id 
> a.cri.dsulli...@bsdad.uchicago.edu’
>  on the IPA DC shows me as a member of the POSIX IPA group 
> (cri_server_administrators_...@ipa.cri.uchicago.edu)
>  as well as the AD domain group in the trusted domain 
> (cri-aaa_server_administrat...@bsdad.uchicago.edu).
>   This remains consistent across any number of successful sshd logins into 
> the DC using my 
> a.cri.dsullivan@bsdad.uchicago.edu 
> account, including after clearing the cache on the DC.
> 
> On the client, I am seeing some unusual behavior.  If I run the commands 
> 'sss_cache -E; service sssd stop ; rm -rf /var/log/sssd/* ; service sssd 
> start’ , then run ‘id 
> a.cri.dsulli...@bsdad.uchicago.edu’,
>  I see the POSIX IPA group as well as the AD domain group as described above 
> (what I presumably want and expect).  However (and this is the unusual part), 
> if I attempt to login via SSH (it will fail with HBAC validation), and then 
> run the ‘id 
> a.cri.dsulli...@bsdad.uchicago.edu’
>  command again , the POSIX IPA group disappears from the list of groups 
> output by the id command.  From what I can tell, this group will not reappear 
> in the group list on the client until the client cache is cleared.  
> Presumably this behavior is related to the HBAC authentication errors I am 
> experiencing.  I have cleared the cache on both the DC and the client using 
> ssh_cache -E and this behavior is still exhibited.  With respect to output 
> from testing:
> 
> 1) The sssd domain log from from the client of the initial id invocation 
> (both groups appear) after clearing the cache (on the client) can be found 
> here (this output contains both groups): 
> https://gist.github.com/dsulli99/7117f8d567cc7cdf727d474b0aeab8da
> 2) The sssd domain log from the client for the failed sshd login (similar to 
> the output I provided yesterday, however re-captured) can be found here 
> (after this operation the IPA group disappears from the list of groups from 
> the id command): 
> https://gist.github.com/dsulli99/668a8799709ff0cd311b321206591124
> 3) The DC log (after the client cache is cleared) of my running the id 
> invocation (from the client) can be found here (this is the DC side of 1) 
> from above. https://gist.github.com/dsulli99/a2a5e80b6a8b143afa20024aa40a7b39
> 4) The DC log of the the failed sshd login into the client (this is the DC 
> side of 2) from above is 
> https://gist.github.com/dsulli99/4e3ba53c942ad78d7487ae51da92007e
> 
> I really appreciate your help with looking at this issue.  As I said I have 
> another machine built from the same image that this is working fine on.  I am 
> going to keep plugging away at this, I will let you know if I come up with 
> anything.
> 
> Dan
> 
> 
> 
> 
> This e-mail is intended only for the use of the individual or entity to which
> it is addressed and may contain information that is privileged and 
> confidential.
> If the reader of this e-mail message is not the intended recipient, you are 
> hereby notified that any dissemination, distribution or copying of this
> communication is prohibited. If 

Re: [Freeipa-users] sudo - differences between Centos 6.5 and Centos 7.0?

[Tomas Simecek]

Hi Lukas,
sorry to say, but nothing helps.

I have just updated IPA server, so that now it is:
[root@svlxxipap ~]# cat /etc/redhat-release
CentOS Linux release 7.2.1511 (Core)

with:
[root@svlxxipap ~]# rpm -qa|grep ipa
ipa-server-trust-ad-4.2.0-15.0.1.el7.centos.17.x86_64
libipa_hbac-1.13.0-40.el7_2.9.x86_64
ipa-python-4.2.0-15.0.1.el7.centos.17.x86_64
ipa-server-dns-4.2.0-15.0.1.el7.centos.17.x86_64
python-iniparse-0.4-9.el7.noarch
ipa-server-4.2.0-15.0.1.el7.centos.17.x86_64
sssd-ipa-1.13.0-40.el7_2.9.x86_64
ipa-admintools-4.2.0-15.0.1.el7.centos.17.x86_64
python-libipa_hbac-1.13.0-40.el7_2.9.x86_64
ipa-client-4.2.0-15.0.1.el7.centos.17.x86_64

I have also changed sudoers to sudo in sssd.conf as you suggested and
restarted sssd.
No difference, still:
[simecek.to...@sd-stc.cz@zp-cml-test ~]$ sudo service sshd restart
[sudo] password for simecek.to...@sd-stc.cz:
simecek.to...@sd-stc.cz is not in the sudoers file.  This incident will be
reported.

I guess I will pilot some more IPA clients to make sure it works reliably
and if yes, I guess we will be able to live with the fact that older
Linuxes doe not offer sudo to AD clients.

Or do you think there is something more to try?

Thanks

T.

2016-07-14 13:32 GMT+02:00 Lukas Slebodnik :

> On (14/07/16 13:06), Tomas Simecek wrote:
> >Hi Lukas,
> >I did as you said.
> >Logs are attached to this mail.
> >
> Thank you very much for provided data.
>
> The main problem is that full refresh of sudo rules did not store any
> rules.
>
> It might be caused by following errors which might be caused by issues
> with old buggy IPA server on CentOS 7.0
>
> [ipa_s2n_save_objects] (0x2000): Updating memberships for
> borek.pa...@sd-stc.cz
> [sysdb_mod_group_member] (0x0080): ldb_modify failed: [No such
> object](32)[ldb_wait: No such object (32)]
> [sysdb_mod_group_member] (0x0400): Error: 2 (No such file or directory)
> [sysdb_update_members_ex] (0x0020): Could not add member [
> borek.pa...@sd-stc.cz] to group [name=acco...@sd-stc.cz,cn=groups,cn=
> sd-stc.cz,cn=sysdb]. Skipping.
> [sysdb_mod_group_member] (0x0080): ldb_modify failed: [No such
> object](32)[ldb_wait: No such object (32)]
> [sysdb_mod_group_member] (0x0400): Error: 2 (No such file or directory)
> [sysdb_update_members_ex] (0x0020): Could not add member [
> borek.pa...@sd-stc.cz] to group [name=borek.pa...@sd-stc.cz,cn=groups,cn=
> sd-stc.cz,cn=sysdb]. Skipping.
>
> Attached is a reduced log.
>
> You might try new feature in sssd-1.13 on el6 which will
> avoid using compat tree for sudo.
>
> Try to change ldap_sudo_search_base from
> ou=sudoers,dc=linuxdomain,dc=cz -> cn=sudo,dc=linuxdomain,dc=cz
>
> It does not mean that it will solve issue with extop plugin
> on IPA server (ipa_s2n_save_objects)
>
> If it does not help then please provide the same data as in previous mail.
> BTW I strogly suspect issues on IPA server on CentOS 7.0.
> It might work on CentOS 7.0 client only by chance.
>
> 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] sudo - differences between Centos 6.5 and Centos 7.0?

[Lukas Slebodnik]

On (14/07/16 13:06), Tomas Simecek wrote:
>Hi Lukas,
>I did as you said.
>Logs are attached to this mail.
>
Thank you very much for provided data.

The main problem is that full refresh of sudo rules did not store any rules.

It might be caused by following errors which might be caused by issues
with old buggy IPA server on CentOS 7.0

[ipa_s2n_save_objects] (0x2000): Updating memberships for borek.pa...@sd-stc.cz
[sysdb_mod_group_member] (0x0080): ldb_modify failed: [No such 
object](32)[ldb_wait: No such object (32)]
[sysdb_mod_group_member] (0x0400): Error: 2 (No such file or directory)
[sysdb_update_members_ex] (0x0020): Could not add member 
[borek.pa...@sd-stc.cz] to group 
[name=acco...@sd-stc.cz,cn=groups,cn=sd-stc.cz,cn=sysdb]. Skipping.
[sysdb_mod_group_member] (0x0080): ldb_modify failed: [No such 
object](32)[ldb_wait: No such object (32)]
[sysdb_mod_group_member] (0x0400): Error: 2 (No such file or directory)
[sysdb_update_members_ex] (0x0020): Could not add member 
[borek.pa...@sd-stc.cz] to group 
[name=borek.pa...@sd-stc.cz,cn=groups,cn=sd-stc.cz,cn=sysdb]. Skipping.

Attached is a reduced log.

You might try new feature in sssd-1.13 on el6 which will
avoid using compat tree for sudo.

Try to change ldap_sudo_search_base from
ou=sudoers,dc=linuxdomain,dc=cz -> cn=sudo,dc=linuxdomain,dc=cz

It does not mean that it will solve issue with extop plugin
on IPA server (ipa_s2n_save_objects)

If it does not help then please provide the same data as in previous mail.
BTW I strogly suspect issues on IPA server on CentOS 7.0.
It might work on CentOS 7.0 client only by chance.

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] Web UI access from outside the home network via port forwarding

[Christophe TREFOIS]

Hi Jan,

Cool doc. Thanks for writing it up!
  

> On 14 Jul 2016, at 07:52, Jan Pazdziora  wrote:
> 
> On Mon, Jul 11, 2016 at 07:00:04PM -0700, Harry Kashouli wrote:
>> 
>> I have a freeipa server set up, and would like to access the Web UI
>> remotely (from outside my home network).
>> 
>> I set up a fresh Fedora 24 server install, and installed freeipa-server.
>> - I own a domain, domain.com
>> - The hostname of my freeipa server is hostname.subdomain.domain.com
>> - My home network domain is subdomain.domain.com
>> 
>> I set up a CNAME hostname.domain.com and port forwardings, and I tested
>> this works with nginx on the same machine; I can successfully see the nginx
>> test page.
>> I then assumed I could do the same with the freeipa Web UI, but when I
>> navigate to http://hostname.domain.com:, it switches to
>> https://hostname.subdomain.domain.com:, and with the
>> following error: "Server not found"
>> 
>> What am I doing wrong?
> 
> There are some more config tweaks likely needed.
> 
> Writeup
> 
>   https://www.adelton.com/freeipa/freeipa-behind-proxy-with-different-name
> 
> should help you resolve the issue.
> 
> -- 
> Jan Pazdziora
> Senior Principal Software Engineer, Identity Management Engineering, Red Hat
> 
> -- 
> 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

[Freeipa-users] Migrating to FreeIPA from an existing Heimdal Kerberos and 389-ds deployment

[Grant Wu]

Hi all,

I'm part of the CMU Computer Club and our Kerberos/LDAP deployment has been
a pain point for quite some time.  I've heard that FreeIPA might be a
solution worth exploring.

I would like to try to avoid user visible disruption if possible, however.
This means that we would like to keep our Kerberos realm name, keep AFS
cross-realm authentication working, etc.  UIDs remaining the same would be
good; I'd have to think about

Essentially all of our clients are various flavors of Debian; mostly Jessie
(we have an unfortunate number of older machines that I hope to upgrade
soon).

Has anyone done something like this before?  Anyone have any ideas what the
migration path would look like or whether this is even possible?

Thanks,

Grant Wu
gran...@andrew.cmu.edu
-- 
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] named-pkcs11 fails on new ipa replica

[Bob Hinton]

Hi,

We are trying to create a new replica on RHEL 7.2

This completes but named-pkcs11 fails to start -

 systemctl status named-pkcs11.service
● named-pkcs11.service - Berkeley Internet Name Domain (DNS) with native
PKCS#11
   Loaded: loaded (/usr/lib/systemd/system/named-pkcs11.service;
disabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Wed 2016-07-13 18:38:15 BST;
51min ago
  Process: 25913 ExecStart=/usr/sbin/named-pkcs11 -u named $OPTIONS
(code=exited, status=1/FAILURE)
  Process: 25910 ExecStartPre=/bin/bash -c if [ !
"$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -z
/etc/named.conf; else echo "Checking of zone files is disabled"; fi
(code=exited, status=0/SUCCESS)

Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]: corporation. 
Support and training for BIND 9 are
Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]: available at
https://www.isc.org/support
Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]:

Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]: adjusted limit on
open files from 4096 to 1048576
Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]: found 1 CPU,
using 1 worker thread
Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]: using 1 UDP
listener per interface
Jul 13 18:38:15 ipa001.mgmt.local systemd[1]: named-pkcs11.service:
control process exited, code=exited status=1
Jul 13 18:38:15 ipa001.mgmt.local systemd[1]: Failed to start Berkeley
Internet Name Domain (DNS) with native PKCS#11.
Jul 13 18:38:15 ipa001.mgmt.local systemd[1]: Unit named-pkcs11.service
entered failed state.
Jul 13 18:38:15 ipa001.mgmt.local systemd[1]: named-pkcs11.service failed.

# /usr/sbin/named-pkcs11 -d 9 -g
13-Jul-2016 19:31:01.283 starting BIND 9.9.4-RedHat-9.9.4-29.el7_2.1 -d 9 -g
13-Jul-2016 19:31:01.283 built with '--build=x86_64-redhat-linux-gnu'
'--host=x86_64-redhat-linux-gnu' '--program-prefix='
'--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr'
'--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc'
'--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64'
'--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib'
'--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-libtool'
'--localstatedir=/var' '--enable-threads' '--enable-ipv6'
'--enable-filter-' '--enable-rrl' '--with-pic' '--disable-static'
'--disable-openssl-version-check' '--enable-exportlib'
'--with-export-libdir=/usr/lib64'
'--with-export-includedir=/usr/include'
'--includedir=/usr/include/bind9' '--enable-native-pkcs11'
'--with-pkcs11=/usr/lib64/pkcs11/libsofthsm2.so' '--with-dlopen=yes'
'--with-dlz-ldap=yes' '--with-dlz-postgres=yes' '--with-dlz-mysql=yes'
'--with-dlz-filesystem=yes' '--with-dlz-bdb=yes' '--with-gssapi=yes'
'--disable-isc-spnego' '--enable-fixed-rrset'
'--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets'
'build_alias=x86_64-redhat-linux-gnu'
'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic'
'LDFLAGS=-Wl,-z,relro ' 'CPPFLAGS= -DDIG_SIGCHASE'
13-Jul-2016 19:31:01.283

13-Jul-2016 19:31:01.284 BIND 9 is maintained by Internet Systems
Consortium,
13-Jul-2016 19:31:01.284 Inc. (ISC), a non-profit 501(c)(3) public-benefit
13-Jul-2016 19:31:01.284 corporation.  Support and training for BIND 9 are
13-Jul-2016 19:31:01.284 available at https://www.isc.org/support
13-Jul-2016 19:31:01.284

13-Jul-2016 19:31:01.284 adjusted limit on open files from 4096 to 1048576
13-Jul-2016 19:31:01.284 found 1 CPU, using 1 worker thread
13-Jul-2016 19:31:01.284 using 1 UDP listener per interface
13-Jul-2016 19:31:01.284 using up to 4096 sockets
13-Jul-2016 19:31:01.284 Registering DLZ_dlopen driver
13-Jul-2016 19:31:01.284 Registering SDLZ driver 'dlopen'
13-Jul-2016 19:31:01.284 Registering DLZ driver 'dlopen'
13-Jul-2016 19:31:01.287 initializing DST: PKCS#11 initialization failed
13-Jul-2016 19:31:01.287 exiting (due to fatal error)

# tail -2 /var/log

Jul 13 19:31:01 ipa001.mgmt.local named-pkcs11[27088]:
ObjectStore.cpp(59): Failed to enumerate object store in
/var/lib/softhsm/tokens/

Jul 13 19:31:01 ipa001.mgmt.local named-pkcs11[27088]: SoftHSM.cpp(456):
Could not load the object store

I've tried "ipa-server-upgrade" and

mv /var/lib/ipa/dnssec/tokens /var/lib/ipa/dnssec/tokens-OLD

ipa-dns-install

But I haven't managed to fix it.

Using "ipactl start -f" means the rest of the ipa services seem to work
properly, but without named.

Is there a way to fix the named issue or is it much simpler to
disconnect the replica, uninstall it and start again ?

Thanks

Bob Hinton

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to 

[Freeipa-users] Sync & BaseDN change

[Brad Cesarone]

Hello

I hope this finds the right thread because the original thread was replied
ot the list and  not my email...

I need to sync to another ldap directory which has a different SUFFIX than
IPA sets up. I successfully imported from our OpenLDAP to IPA but I still
need to sync with a separate master ldap server.
So the provider server suffix is dc=example,dc=com. This suffix is
different than the DNS suffix and there is no kerberos realm to match too
for the provider side. IPA server suffix is dc=domain, dc=com.
So the two options I see is create a script which connects and compares
both ldaps ensuring it can match to different suffixs or some how change
the suffix of the originally installed
-- 
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] Replication Agreement issues noticed with repl-monitor.pl

[Martin Kosek]

On 07/13/2016 04:24 AM, Devin Acosta wrote:
> 
> I was trying to create another Replica but then noticed it was constantly 
> having 
> issues trying to finish the joining of the replication. I then ran the 
> command: 
> repl-monitor.pl , It appears i have several 
> replicaid's 
> and they seem to be having issues, wondering if this is adding to my issue.
> 
> Anyone know how I can resolve this issue and clean up the replication???
> 
> See attached Screenshot.

I wonder if cleaning RUVs help:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/trouble-replica.html#trouble-repl-cleanruv

-- 
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 - differences between Centos 6.5 and Centos 7.0?

[Lukas Slebodnik]

On (14/07/16 12:43), Tomas Simecek wrote:
>Thanks Lukas,
>to be honest I am not sure what do you mean by "Please test with id
>simecek.to...@sd-stc.cz."
>It is the user I am testing with all the time.
>
>Here is what I see on client where sudo does not work:
>[simecek.to...@sd-stc.cz@zp-cml-test ~]$ id
>uid=988604700(simecek.to...@sd-stc.cz) gid=988604700(simecek.to...@sd-stc.cz)
>groups=988604700(simecek.to...@sd-stc.cz),43124(grpunixadmins),988600513(domain
>us...@sd-stc.cz),988604182(acco...@sd-stc.cz),988604754(mfcr_...@sd-stc.cz
>),988604825(unixadm...@sd-stc.cz),988604833(wifiadm...@sd-stc.cz)
>
hmm, the user is member of grpunixadmins. Then I wonder why sssd could not find
a sudo rules for the user.

I would like to see full log file + dump of sssd cache.
Please:
* clean cache and log files on client
  rm -f /var/lib/sss/db/* /var/log/sssd/*
* enable debug_level=9 in domain section and sudo
* restart sssd
* authernticate with usersimecek.to...@sd-stc.cz
* try sudo.
* send all sssd log files
* provide dump of sssd cache
  ldbsearch -H /var/lib/sss/db/cache_$domain.ldb
  (utility ldbsearch is part of package ldb-tools

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] sudo - differences between Centos 6.5 and Centos 7.0?

[Tomas Simecek]

Thanks Lukas,
to be honest I am not sure what do you mean by "Please test with id
simecek.to...@sd-stc.cz."
It is the user I am testing with all the time.

Here is what I see on client where sudo does not work:
[simecek.to...@sd-stc.cz@zp-cml-test ~]$ id
uid=988604700(simecek.to...@sd-stc.cz) gid=988604700(simecek.to...@sd-stc.cz)
groups=988604700(simecek.to...@sd-stc.cz),43124(grpunixadmins),988600513(domain
us...@sd-stc.cz),988604182(acco...@sd-stc.cz),988604754(mfcr_...@sd-stc.cz
),988604825(unixadm...@sd-stc.cz),988604833(wifiadm...@sd-stc.cz)

You can see Centos 6.6 client knows about all the groups assigned to the
users, incl. AD groups (unixadmins), which seems funny to me.

You are right, IPA server is Centos 7.0 and functional client is Centos 7.0
as well. Both login and sudo work on client with Centos 7.0.
Rules on IPA server are set to work on both clients, but work only on 7.0.
If I run update on server, it would update ipa-server from v.
4.2.0-15.0.1.el7.centos.6.1 to v. 4.2.0-15.0.1.el7.centos.17.

Does it make sense now?

Thanks

T.


2016-07-14 12:21 GMT+02:00 Lukas Slebodnik :

> On (14/07/16 11:26), Tomas Simecek wrote:
> >Hi Lukas,
> >we have Active Directory group "UnixAdmins"
> >.
> >We have IPA external group ad_admins_external
> >, which has
> >Windows "UnixAdmins" group as a member.
> >We have local IPA group grpunixadmins
> >, which has
> >ad_admins_external group as a member.
> >So from that perspective user simecek.to...@sd-stc.cz is a member of
> >grpunixadmins .
> >That setup works for ssh logins and for sudo on Centos 7.0.
> >
> If user is member of group in IPA it does not mean that
> it's properly propagated to client :-)
>
> I can see few errors in log
> >(Thu Jul 14 09:53:57 2016) [sssd[be[linuxdomain.cz]]]
> >[sysdb_mod_group_member] (0x0080): ldb_modify failed: [No such
> >object](32)[ldb_wait: No such object (32)]
> >(Thu Jul 14 09:53:57 2016) [sssd[be[linuxdomain.cz]]]
> >[sysdb_mod_group_member] (0x0400): Error: 2 (No such file or directory)
> >(Thu Jul 14 09:53:57 2016) [sssd[be[linuxdomain.cz]]]
> >[sysdb_update_members_ex] (0x0020): Could not add member [
> >simecek.to...@sd-stc.cz] to group [name=simecek.to...@sd-stc.cz
> >,cn=groups,cn=sd-stc.cz,cn=sysdb]. Skipping.
> >(Thu Jul 14 09:53:57 2016) [sssd[be[linuxdomain.cz]]]
> >[ipa_s2n_save_objects] (0x2000): Updating memberships for
> >simecek.to...@sd-stc.cz
> >(Thu Jul 14 09:53:57 2016) [sssd[be[linuxdomain.cz]]]
> >[sysdb_mod_group_member] (0x0080): ldb_modify failed: [No such
> >object](32)[ldb_wait: No such object (32)]
> >(Thu Jul 14 09:53:57 2016) [sssd[be[linuxdomain.cz]]]
> >[sysdb_mod_group_member] (0x0400): Error: 2 (No such file or directory)
> >(Thu Jul 14 09:53:57 2016) [sssd[be[linuxdomain.cz]]]
> >[sysdb_update_members_ex] (0x0020): Could not add member [
> >simecek.to...@sd-stc.cz] to group [name=simecek.to...@sd-stc.cz
> >,cn=groups,cn=sd-stc.cz,cn=sysdb]. Skipping.
>
> Please test with id simecek.to...@sd-stc.cz.
> I'm preatty sure that you will not see a group grpunixadmins.
>
> BTW according to domain logs it looks like a bug with extop plugin
> on freeipa server. I assume that ipa server is on CentOS 7.0
> because you mention it works on Centos 7.0.
>
> I would strongly recommend to upgrade server to 7.2
>
> 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] sudo - differences between Centos 6.5 and Centos 7.0?

[Lukas Slebodnik]

On (14/07/16 11:26), Tomas Simecek wrote:
>Hi Lukas,
>we have Active Directory group "UnixAdmins"
>.
>We have IPA external group ad_admins_external
>, which has
>Windows "UnixAdmins" group as a member.
>We have local IPA group grpunixadmins
>, which has
>ad_admins_external group as a member.
>So from that perspective user simecek.to...@sd-stc.cz is a member of
>grpunixadmins .
>That setup works for ssh logins and for sudo on Centos 7.0.
>
If user is member of group in IPA it does not mean that
it's properly propagated to client :-)

I can see few errors in log
>(Thu Jul 14 09:53:57 2016) [sssd[be[linuxdomain.cz]]]
>[sysdb_mod_group_member] (0x0080): ldb_modify failed: [No such
>object](32)[ldb_wait: No such object (32)]
>(Thu Jul 14 09:53:57 2016) [sssd[be[linuxdomain.cz]]]
>[sysdb_mod_group_member] (0x0400): Error: 2 (No such file or directory)
>(Thu Jul 14 09:53:57 2016) [sssd[be[linuxdomain.cz]]]
>[sysdb_update_members_ex] (0x0020): Could not add member [
>simecek.to...@sd-stc.cz] to group [name=simecek.to...@sd-stc.cz
>,cn=groups,cn=sd-stc.cz,cn=sysdb]. Skipping.
>(Thu Jul 14 09:53:57 2016) [sssd[be[linuxdomain.cz]]]
>[ipa_s2n_save_objects] (0x2000): Updating memberships for
>simecek.to...@sd-stc.cz
>(Thu Jul 14 09:53:57 2016) [sssd[be[linuxdomain.cz]]]
>[sysdb_mod_group_member] (0x0080): ldb_modify failed: [No such
>object](32)[ldb_wait: No such object (32)]
>(Thu Jul 14 09:53:57 2016) [sssd[be[linuxdomain.cz]]]
>[sysdb_mod_group_member] (0x0400): Error: 2 (No such file or directory)
>(Thu Jul 14 09:53:57 2016) [sssd[be[linuxdomain.cz]]]
>[sysdb_update_members_ex] (0x0020): Could not add member [
>simecek.to...@sd-stc.cz] to group [name=simecek.to...@sd-stc.cz
>,cn=groups,cn=sd-stc.cz,cn=sysdb]. Skipping.

Please test with id simecek.to...@sd-stc.cz.
I'm preatty sure that you will not see a group grpunixadmins.

BTW according to domain logs it looks like a bug with extop plugin
on freeipa server. I assume that ipa server is on CentOS 7.0
because you mention it works on Centos 7.0.

I would strongly recommend to upgrade server to 7.2

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] sudo - differences between Centos 6.5 and Centos 7.0?

[Tomas Simecek]

Hi Rob,
thanks, but this is not the case.
Firstly, for initial test purposes I am not limiting sudo to specific
commands, in the rule it is set to "any".
Secondly, it fails even in non-symlink cases:

[root@zp-cml-test ~]# which service
/sbin/service
[root@zp-cml-test ~]# ll /sbin/service
-rwxr-xr-x. 1 root root 1694 Oct 16  2014 /sbin/service
[root@zp-cml-test ~]# logout
[simecek.to...@sd-stc.cz@zp-cml-test ~]$ sudo service sshd restart
[sudo] password for simecek.to...@sd-stc.cz:
simecek.to...@sd-stc.cz is not in the sudoers file.  This incident will be
reported.

Thanks anyway, let me know if something else comes to your mind.

Tomas

2016-07-14 11:51 GMT+02:00 Rob Verduijn :

> hi,
>
> just a long shot here..
>
> I've been battling sudo for a couple days now and found that my issue was
> one related to symlinks
> on centos7 'which cat' says /bin/cat
> but on centos /bin is a symlink to /usr/bin and sudo knows a symlink when
> it sees one and to prevent abuse it requires the 'real' path for the sudo
> rule :  ALL=(ALL) /usr/bin/cat
> on centos6 which cat also says /bin/cat but since /bin is not a symlink it
> requires the sudo rule to be  ALL=(ALL) /bin/cat
> so for the sudo to work on both centos6 and centos7 you would require 2
> sudo rules.
>
> Ignore me if this is irrelevant.
>
> Just my 2 cents
> Rob
>
> 2016-07-14 10:38 GMT+02:00 Lukas Slebodnik :
>
>> On (14/07/16 10:09), Tomas Simecek wrote:
>> >Thanks all of you guys,
>> >I have updated to:
>> >sssd-krb5-common-1.13.3-22.el6_8.4.x86_64
>> >sssd-1.13.3-22.el6_8.4.x86_64
>> >sssd-ldap-1.13.3-22.el6_8.4.x86_64
>> >sssd-client-1.13.3-22.el6_8.4.x86_64
>> >sssd-ad-1.13.3-22.el6_8.4.x86_64
>> >sssd-proxy-1.13.3-22.el6_8.4.x86_64
>> >libsss_idmap-1.13.3-22.el6_8.4.x86_64
>> >sssd-common-1.13.3-22.el6_8.4.x86_64
>> >sssd-ipa-1.13.3-22.el6_8.4.x86_64
>> >python-sssdconfig-1.13.3-22.el6_8.4.noarch
>> >sssd-krb5-1.13.3-22.el6_8.4.x86_64
>> >sssd-common-pac-1.13.3-22.el6_8.4.x86_64
>> >(there does not seem to be libsss_sudo in Centos as suggested by Danila).
>> >and restarted sssd.
>> >
>> >There are two rules enabled. One HBAC as I presented earlier:
>> >  Rule name: Unixari na test servery
>> >  Enabled: TRUE
>> >  User Groups: grpunixadmins
>> >  Hosts: spcss-2t-www.linuxdomain.cz, zp-cml-test.linuxdomain.cz
>> >  Services: login, sshd, sudo, sudo-i, su, su-l
>> >
>> >and one sudo rule:
>> >Rule name: Pokusne
>> >  Enabled: TRUE
>> >  Command category: all
>> >  User Groups: grpunixadmins
>> >  Hosts: spcss-2t-www.linuxdomain.cz, zp-cml-test.linuxdomain.cz
>> >
>> >Default "all-access" rules are disabled.
>> >
>> >When I try to sudo as AD user (member of grpunixadmins) on Centos 6.6, I
>> >still get:
>> >
>> >[simecek.to...@sd-stc.cz@zp-cml-test ~]$ sudo cat /etc/nsswitch.conf
>> >[sudo] password for simecek.to...@sd-stc.cz:
>> >simecek.to...@sd-stc.cz is not in the sudoers file.  This incident will
>> be
>> >reported.
>> >
>> >It works fine on Centos 7 (spcss-2t-www.linuxdomain.cz).
>> >
>> >sssd.conf:
>> >[domain/linuxdomain.cz]
>> >cache_credentials = True
>> >krb5_store_password_if_offline = True
>> >ipa_domain = linuxdomain.cz
>> >id_provider = ipa
>> >krb5_realm = LINUXDOMAIN.CZ
>> >auth_provider = ipa
>> >access_provider = ipa
>> >ipa_hostname = zp-cml-test.linuxdomain.cz
>> >chpass_provider = ipa
>> >ipa_server = svlxxipap.linuxdomain.cz
>> >ldap_tls_cacert = /etc/ipa/ca.crt
>> >override_shell = /bin/bash
>> >sudo_provider = ipa
>> >ldap_uri = ldap://svlxxipap.linuxdomain.cz
>> >ldap_sudo_search_base = ou=sudoers,dc=linuxdomain,dc=cz
>> >ldap_sasl_mech = GSSAPI
>> >#ldap_sasl_authid = host/zp-cml-test.linuxdomain...@linuxdomain.cz
>> >ldap_sasl_authid = host/zp-cml-test.linuxdomain.cz
>> >ldap_sasl_realm = LINUXDOMAIN.CZ
>> >krb5_server = svlxxipap.linuxdomain.cz
>> >debug_level = 0x3ff0
>> >[sssd]
>> >services = nss, sudo, pam, ssh
>> >config_file_version = 2
>> >domains = linuxdomain.cz
>> >[nss]
>> >homedir_substring = /home
>> >[pam]
>> >[sudo]
>> >debug_level = 0x3ff0
>> >[autofs]
>> >[ssh]
>> >[pac]
>> >[ifp]
>> >
>> >
>> >sssd_sudo.log from the moment I tried sudo:
>> >(Thu Jul 14 09:53:41 2016) [sssd[sudo]] [sysdb_search_group_by_gid]
>> >(0x0400): No such entry
>> >(Thu Jul 14 09:53:41 2016) [sssd[sudo]]
>> [sudosrv_get_sudorules_query_cache]
>> >(0x0200): Searching sysdb with
>> >[(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=
>> >simecek.to...@sd-stc.cz)(sudoUser=#988604700)(sudoUser=%domain\
>> >20us...@sd-stc.cz)(sudoUser=%unixadm...@sd-stc.cz
>> >)(sudoUser=%grpunixadmins)(sudoUser=%mfcr_...@sd-stc.cz)(sudoUser=%
>> >acco...@sd-stc.cz)(sudoUser=%wifiadm...@sd-stc.cz
>> >)(sudoUser=+*))(&(dataExpireTimestamp<=1468482821)))]
>> >(Thu Jul 14 09:53:41 2016) [sssd[sudo]] [sudosrv_get_rules] (0x2000):
>> About
>> >to get sudo rules from cache
>> >(Thu Jul 14 09:53:41 2016) [sssd[sudo]] [sysdb_search_group_by_gid]
>> >(0x0400): No such entry
>> >(Thu Jul 14 09:53:41 2016) 

Re: [Freeipa-users] sudo - differences between Centos 6.5 and Centos 7.0?

[Rob Verduijn]

hi,

just a long shot here..

I've been battling sudo for a couple days now and found that my issue was
one related to symlinks
on centos7 'which cat' says /bin/cat
but on centos /bin is a symlink to /usr/bin and sudo knows a symlink when
it sees one and to prevent abuse it requires the 'real' path for the sudo
rule :  ALL=(ALL) /usr/bin/cat
on centos6 which cat also says /bin/cat but since /bin is not a symlink it
requires the sudo rule to be  ALL=(ALL) /bin/cat
so for the sudo to work on both centos6 and centos7 you would require 2
sudo rules.

Ignore me if this is irrelevant.

Just my 2 cents
Rob

2016-07-14 10:38 GMT+02:00 Lukas Slebodnik :

> On (14/07/16 10:09), Tomas Simecek wrote:
> >Thanks all of you guys,
> >I have updated to:
> >sssd-krb5-common-1.13.3-22.el6_8.4.x86_64
> >sssd-1.13.3-22.el6_8.4.x86_64
> >sssd-ldap-1.13.3-22.el6_8.4.x86_64
> >sssd-client-1.13.3-22.el6_8.4.x86_64
> >sssd-ad-1.13.3-22.el6_8.4.x86_64
> >sssd-proxy-1.13.3-22.el6_8.4.x86_64
> >libsss_idmap-1.13.3-22.el6_8.4.x86_64
> >sssd-common-1.13.3-22.el6_8.4.x86_64
> >sssd-ipa-1.13.3-22.el6_8.4.x86_64
> >python-sssdconfig-1.13.3-22.el6_8.4.noarch
> >sssd-krb5-1.13.3-22.el6_8.4.x86_64
> >sssd-common-pac-1.13.3-22.el6_8.4.x86_64
> >(there does not seem to be libsss_sudo in Centos as suggested by Danila).
> >and restarted sssd.
> >
> >There are two rules enabled. One HBAC as I presented earlier:
> >  Rule name: Unixari na test servery
> >  Enabled: TRUE
> >  User Groups: grpunixadmins
> >  Hosts: spcss-2t-www.linuxdomain.cz, zp-cml-test.linuxdomain.cz
> >  Services: login, sshd, sudo, sudo-i, su, su-l
> >
> >and one sudo rule:
> >Rule name: Pokusne
> >  Enabled: TRUE
> >  Command category: all
> >  User Groups: grpunixadmins
> >  Hosts: spcss-2t-www.linuxdomain.cz, zp-cml-test.linuxdomain.cz
> >
> >Default "all-access" rules are disabled.
> >
> >When I try to sudo as AD user (member of grpunixadmins) on Centos 6.6, I
> >still get:
> >
> >[simecek.to...@sd-stc.cz@zp-cml-test ~]$ sudo cat /etc/nsswitch.conf
> >[sudo] password for simecek.to...@sd-stc.cz:
> >simecek.to...@sd-stc.cz is not in the sudoers file.  This incident will
> be
> >reported.
> >
> >It works fine on Centos 7 (spcss-2t-www.linuxdomain.cz).
> >
> >sssd.conf:
> >[domain/linuxdomain.cz]
> >cache_credentials = True
> >krb5_store_password_if_offline = True
> >ipa_domain = linuxdomain.cz
> >id_provider = ipa
> >krb5_realm = LINUXDOMAIN.CZ
> >auth_provider = ipa
> >access_provider = ipa
> >ipa_hostname = zp-cml-test.linuxdomain.cz
> >chpass_provider = ipa
> >ipa_server = svlxxipap.linuxdomain.cz
> >ldap_tls_cacert = /etc/ipa/ca.crt
> >override_shell = /bin/bash
> >sudo_provider = ipa
> >ldap_uri = ldap://svlxxipap.linuxdomain.cz
> >ldap_sudo_search_base = ou=sudoers,dc=linuxdomain,dc=cz
> >ldap_sasl_mech = GSSAPI
> >#ldap_sasl_authid = host/zp-cml-test.linuxdomain...@linuxdomain.cz
> >ldap_sasl_authid = host/zp-cml-test.linuxdomain.cz
> >ldap_sasl_realm = LINUXDOMAIN.CZ
> >krb5_server = svlxxipap.linuxdomain.cz
> >debug_level = 0x3ff0
> >[sssd]
> >services = nss, sudo, pam, ssh
> >config_file_version = 2
> >domains = linuxdomain.cz
> >[nss]
> >homedir_substring = /home
> >[pam]
> >[sudo]
> >debug_level = 0x3ff0
> >[autofs]
> >[ssh]
> >[pac]
> >[ifp]
> >
> >
> >sssd_sudo.log from the moment I tried sudo:
> >(Thu Jul 14 09:53:41 2016) [sssd[sudo]] [sysdb_search_group_by_gid]
> >(0x0400): No such entry
> >(Thu Jul 14 09:53:41 2016) [sssd[sudo]]
> [sudosrv_get_sudorules_query_cache]
> >(0x0200): Searching sysdb with
> >[(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=
> >simecek.to...@sd-stc.cz)(sudoUser=#988604700)(sudoUser=%domain\
> >20us...@sd-stc.cz)(sudoUser=%unixadm...@sd-stc.cz
> >)(sudoUser=%grpunixadmins)(sudoUser=%mfcr_...@sd-stc.cz)(sudoUser=%
> >acco...@sd-stc.cz)(sudoUser=%wifiadm...@sd-stc.cz
> >)(sudoUser=+*))(&(dataExpireTimestamp<=1468482821)))]
> >(Thu Jul 14 09:53:41 2016) [sssd[sudo]] [sudosrv_get_rules] (0x2000):
> About
> >to get sudo rules from cache
> >(Thu Jul 14 09:53:41 2016) [sssd[sudo]] [sysdb_search_group_by_gid]
> >(0x0400): No such entry
> >(Thu Jul 14 09:53:41 2016) [sssd[sudo]]
> [sudosrv_get_sudorules_query_cache]
> >(0x0200): Searching sysdb with
> >[(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=
> simecek.to...@sd-stc.cz
> >)(sudoUser=#988604700)(sudoUser=%domain\20us...@sd-stc.cz)(sudoUser=%
> >unixadm...@sd-stc.cz)(sudoUser=%grpunixadmins)(sudoUser=%
> mfcr_...@sd-stc.cz
> >)(sudoUser=%acco...@sd-stc.cz)(sudoUser=%wifiadm...@sd-stc.cz
> >)(sudoUser=+*)))]
> >(Thu Jul 14 09:53:41 2016) [sssd[sudo]] [sudosrv_get_sudorules_from_cache]
> >(0x0400): Returning 0 rules for [simecek.to...@sd-stc.cz]
> >(Thu Jul 14 09:53:47 2016) [sssd[sudo]] [client_recv] (0x0200): Client
> >disconnected!
> >(Thu Jul 14 09:53:47 2016) [sssd[sudo]] [client_destructor] (0x2000):
> >Terminated client [0x260b690][17]
> >(Thu Jul 14 09:53:51 2016) [sssd[sudo]] [sbus_message_handler] (0x2000):
> >Received SBUS method 

Re: [Freeipa-users] sudo - differences between Centos 6.5 and Centos 7.0?

[Tomas Simecek]

Hi Lukas,
we have Active Directory group "UnixAdmins"
.
We have IPA external group ad_admins_external
, which has
Windows "UnixAdmins" group as a member.
We have local IPA group grpunixadmins
, which has
ad_admins_external group as a member.
So from that perspective user simecek.to...@sd-stc.cz is a member of
grpunixadmins .
That setup works for ssh logins and for sudo on Centos 7.0.

It is as per installation document
https://www.freeipa.org/page/Active_Directory_trust_setup

Correct me if I am wrong, but if it works on Client 1, it should also work
on Client 2.


T.

2016-07-14 10:38 GMT+02:00 Lukas Slebodnik :

> On (14/07/16 10:09), Tomas Simecek wrote:
> >Thanks all of you guys,
> >I have updated to:
> >sssd-krb5-common-1.13.3-22.el6_8.4.x86_64
> >sssd-1.13.3-22.el6_8.4.x86_64
> >sssd-ldap-1.13.3-22.el6_8.4.x86_64
> >sssd-client-1.13.3-22.el6_8.4.x86_64
> >sssd-ad-1.13.3-22.el6_8.4.x86_64
> >sssd-proxy-1.13.3-22.el6_8.4.x86_64
> >libsss_idmap-1.13.3-22.el6_8.4.x86_64
> >sssd-common-1.13.3-22.el6_8.4.x86_64
> >sssd-ipa-1.13.3-22.el6_8.4.x86_64
> >python-sssdconfig-1.13.3-22.el6_8.4.noarch
> >sssd-krb5-1.13.3-22.el6_8.4.x86_64
> >sssd-common-pac-1.13.3-22.el6_8.4.x86_64
> >(there does not seem to be libsss_sudo in Centos as suggested by Danila).
> >and restarted sssd.
> >
> >There are two rules enabled. One HBAC as I presented earlier:
> >  Rule name: Unixari na test servery
> >  Enabled: TRUE
> >  User Groups: grpunixadmins
> >  Hosts: spcss-2t-www.linuxdomain.cz, zp-cml-test.linuxdomain.cz
> >  Services: login, sshd, sudo, sudo-i, su, su-l
> >
> >and one sudo rule:
> >Rule name: Pokusne
> >  Enabled: TRUE
> >  Command category: all
> >  User Groups: grpunixadmins
> >  Hosts: spcss-2t-www.linuxdomain.cz, zp-cml-test.linuxdomain.cz
> >
> >Default "all-access" rules are disabled.
> >
> >When I try to sudo as AD user (member of grpunixadmins) on Centos 6.6, I
> >still get:
> >
> >[simecek.to...@sd-stc.cz@zp-cml-test ~]$ sudo cat /etc/nsswitch.conf
> >[sudo] password for simecek.to...@sd-stc.cz:
> >simecek.to...@sd-stc.cz is not in the sudoers file.  This incident will
> be
> >reported.
> >
> >It works fine on Centos 7 (spcss-2t-www.linuxdomain.cz).
> >
> >sssd.conf:
> >[domain/linuxdomain.cz]
> >cache_credentials = True
> >krb5_store_password_if_offline = True
> >ipa_domain = linuxdomain.cz
> >id_provider = ipa
> >krb5_realm = LINUXDOMAIN.CZ
> >auth_provider = ipa
> >access_provider = ipa
> >ipa_hostname = zp-cml-test.linuxdomain.cz
> >chpass_provider = ipa
> >ipa_server = svlxxipap.linuxdomain.cz
> >ldap_tls_cacert = /etc/ipa/ca.crt
> >override_shell = /bin/bash
> >sudo_provider = ipa
> >ldap_uri = ldap://svlxxipap.linuxdomain.cz
> >ldap_sudo_search_base = ou=sudoers,dc=linuxdomain,dc=cz
> >ldap_sasl_mech = GSSAPI
> >#ldap_sasl_authid = host/zp-cml-test.linuxdomain...@linuxdomain.cz
> >ldap_sasl_authid = host/zp-cml-test.linuxdomain.cz
> >ldap_sasl_realm = LINUXDOMAIN.CZ
> >krb5_server = svlxxipap.linuxdomain.cz
> >debug_level = 0x3ff0
> >[sssd]
> >services = nss, sudo, pam, ssh
> >config_file_version = 2
> >domains = linuxdomain.cz
> >[nss]
> >homedir_substring = /home
> >[pam]
> >[sudo]
> >debug_level = 0x3ff0
> >[autofs]
> >[ssh]
> >[pac]
> >[ifp]
> >
> >
> >sssd_sudo.log from the moment I tried sudo:
> >(Thu Jul 14 09:53:41 2016) [sssd[sudo]] [sysdb_search_group_by_gid]
> >(0x0400): No such entry
> >(Thu Jul 14 09:53:41 2016) [sssd[sudo]]
> [sudosrv_get_sudorules_query_cache]
> >(0x0200): Searching sysdb with
> >[(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=
> >simecek.to...@sd-stc.cz)(sudoUser=#988604700)(sudoUser=%domain\
> >20us...@sd-stc.cz)(sudoUser=%unixadm...@sd-stc.cz
> >)(sudoUser=%grpunixadmins)(sudoUser=%mfcr_...@sd-stc.cz)(sudoUser=%
> >acco...@sd-stc.cz)(sudoUser=%wifiadm...@sd-stc.cz
> >)(sudoUser=+*))(&(dataExpireTimestamp<=1468482821)))]
> >(Thu Jul 14 09:53:41 2016) [sssd[sudo]] [sudosrv_get_rules] (0x2000):
> About
> >to get sudo rules from cache
> >(Thu Jul 14 09:53:41 2016) [sssd[sudo]] [sysdb_search_group_by_gid]
> >(0x0400): No such entry
> >(Thu Jul 14 09:53:41 2016) [sssd[sudo]]
> [sudosrv_get_sudorules_query_cache]
> >(0x0200): Searching sysdb with
> >[(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=
> simecek.to...@sd-stc.cz
> >)(sudoUser=#988604700)(sudoUser=%domain\20us...@sd-stc.cz)(sudoUser=%
> >unixadm...@sd-stc.cz)(sudoUser=%grpunixadmins)(sudoUser=%
> mfcr_...@sd-stc.cz
> >)(sudoUser=%acco...@sd-stc.cz)(sudoUser=%wifiadm...@sd-stc.cz
> >)(sudoUser=+*)))]
> >(Thu Jul 14 09:53:41 2016) [sssd[sudo]] [sudosrv_get_sudorules_from_cache]
> >(0x0400): Returning 0 rules for [simecek.to...@sd-stc.cz]
> >(Thu Jul 14 09:53:47 2016) [sssd[sudo]] [client_recv] (0x0200): Client
> >disconnected!
> >(Thu Jul 14 

Re: [Freeipa-users] sudo - differences between Centos 6.5 and Centos 7.0?

[Lukas Slebodnik]

On (14/07/16 10:09), Tomas Simecek wrote:
>Thanks all of you guys,
>I have updated to:
>sssd-krb5-common-1.13.3-22.el6_8.4.x86_64
>sssd-1.13.3-22.el6_8.4.x86_64
>sssd-ldap-1.13.3-22.el6_8.4.x86_64
>sssd-client-1.13.3-22.el6_8.4.x86_64
>sssd-ad-1.13.3-22.el6_8.4.x86_64
>sssd-proxy-1.13.3-22.el6_8.4.x86_64
>libsss_idmap-1.13.3-22.el6_8.4.x86_64
>sssd-common-1.13.3-22.el6_8.4.x86_64
>sssd-ipa-1.13.3-22.el6_8.4.x86_64
>python-sssdconfig-1.13.3-22.el6_8.4.noarch
>sssd-krb5-1.13.3-22.el6_8.4.x86_64
>sssd-common-pac-1.13.3-22.el6_8.4.x86_64
>(there does not seem to be libsss_sudo in Centos as suggested by Danila).
>and restarted sssd.
>
>There are two rules enabled. One HBAC as I presented earlier:
>  Rule name: Unixari na test servery
>  Enabled: TRUE
>  User Groups: grpunixadmins
>  Hosts: spcss-2t-www.linuxdomain.cz, zp-cml-test.linuxdomain.cz
>  Services: login, sshd, sudo, sudo-i, su, su-l
>
>and one sudo rule:
>Rule name: Pokusne
>  Enabled: TRUE
>  Command category: all
>  User Groups: grpunixadmins
>  Hosts: spcss-2t-www.linuxdomain.cz, zp-cml-test.linuxdomain.cz
>
>Default "all-access" rules are disabled.
>
>When I try to sudo as AD user (member of grpunixadmins) on Centos 6.6, I
>still get:
>
>[simecek.to...@sd-stc.cz@zp-cml-test ~]$ sudo cat /etc/nsswitch.conf
>[sudo] password for simecek.to...@sd-stc.cz:
>simecek.to...@sd-stc.cz is not in the sudoers file.  This incident will be
>reported.
>
>It works fine on Centos 7 (spcss-2t-www.linuxdomain.cz).
>
>sssd.conf:
>[domain/linuxdomain.cz]
>cache_credentials = True
>krb5_store_password_if_offline = True
>ipa_domain = linuxdomain.cz
>id_provider = ipa
>krb5_realm = LINUXDOMAIN.CZ
>auth_provider = ipa
>access_provider = ipa
>ipa_hostname = zp-cml-test.linuxdomain.cz
>chpass_provider = ipa
>ipa_server = svlxxipap.linuxdomain.cz
>ldap_tls_cacert = /etc/ipa/ca.crt
>override_shell = /bin/bash
>sudo_provider = ipa
>ldap_uri = ldap://svlxxipap.linuxdomain.cz
>ldap_sudo_search_base = ou=sudoers,dc=linuxdomain,dc=cz
>ldap_sasl_mech = GSSAPI
>#ldap_sasl_authid = host/zp-cml-test.linuxdomain...@linuxdomain.cz
>ldap_sasl_authid = host/zp-cml-test.linuxdomain.cz
>ldap_sasl_realm = LINUXDOMAIN.CZ
>krb5_server = svlxxipap.linuxdomain.cz
>debug_level = 0x3ff0
>[sssd]
>services = nss, sudo, pam, ssh
>config_file_version = 2
>domains = linuxdomain.cz
>[nss]
>homedir_substring = /home
>[pam]
>[sudo]
>debug_level = 0x3ff0
>[autofs]
>[ssh]
>[pac]
>[ifp]
>
>
>sssd_sudo.log from the moment I tried sudo:
>(Thu Jul 14 09:53:41 2016) [sssd[sudo]] [sysdb_search_group_by_gid]
>(0x0400): No such entry
>(Thu Jul 14 09:53:41 2016) [sssd[sudo]] [sudosrv_get_sudorules_query_cache]
>(0x0200): Searching sysdb with
>[(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=
>simecek.to...@sd-stc.cz)(sudoUser=#988604700)(sudoUser=%domain\
>20us...@sd-stc.cz)(sudoUser=%unixadm...@sd-stc.cz
>)(sudoUser=%grpunixadmins)(sudoUser=%mfcr_...@sd-stc.cz)(sudoUser=%
>acco...@sd-stc.cz)(sudoUser=%wifiadm...@sd-stc.cz
>)(sudoUser=+*))(&(dataExpireTimestamp<=1468482821)))]
>(Thu Jul 14 09:53:41 2016) [sssd[sudo]] [sudosrv_get_rules] (0x2000): About
>to get sudo rules from cache
>(Thu Jul 14 09:53:41 2016) [sssd[sudo]] [sysdb_search_group_by_gid]
>(0x0400): No such entry
>(Thu Jul 14 09:53:41 2016) [sssd[sudo]] [sudosrv_get_sudorules_query_cache]
>(0x0200): Searching sysdb with
>[(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=simecek.to...@sd-stc.cz
>)(sudoUser=#988604700)(sudoUser=%domain\20us...@sd-stc.cz)(sudoUser=%
>unixadm...@sd-stc.cz)(sudoUser=%grpunixadmins)(sudoUser=%mfcr_...@sd-stc.cz
>)(sudoUser=%acco...@sd-stc.cz)(sudoUser=%wifiadm...@sd-stc.cz
>)(sudoUser=+*)))]
>(Thu Jul 14 09:53:41 2016) [sssd[sudo]] [sudosrv_get_sudorules_from_cache]
>(0x0400): Returning 0 rules for [simecek.to...@sd-stc.cz]
>(Thu Jul 14 09:53:47 2016) [sssd[sudo]] [client_recv] (0x0200): Client
>disconnected!
>(Thu Jul 14 09:53:47 2016) [sssd[sudo]] [client_destructor] (0x2000):
>Terminated client [0x260b690][17]
>(Thu Jul 14 09:53:51 2016) [sssd[sudo]] [sbus_message_handler] (0x2000):
>Received SBUS method org.freedesktop.sssd.service.ping on path
>/org/freedesktop/sssd/service
>(Thu Jul 14 09:53:51 2016) [sssd[sudo]] [sbus_get_sender_id_send] (0x2000):
>Not a sysbus message, quit
>(Thu Jul 14 09:53:55 2016) [sssd[sudo]] [accept_fd_handler] (0x0400):
>Client connected!
>(Thu Jul 14 09:53:55 2016) [sssd[sudo]] [sss_cmd_get_version] (0x0200):
>Received client version [1].
>(Thu Jul 14 09:53:55 2016) [sssd[sudo]] [sss_cmd_get_version] (0x0200):
>Offered version [1].
>(Thu Jul 14 09:53:55 2016) [sssd[sudo]] [sudosrv_cmd] (0x2000): Using
>protocol version [1]
>(Thu Jul 14 09:53:55 2016) [sssd[sudo]] [sss_parse_name_for_domains]
>(0x0200): name 'simecek.to...@sd-stc.cz' matched expression for domain '
>sd-stc.cz', user is simecek.tomas
>(Thu Jul 14 09:53:55 2016) [sssd[sudo]] [sss_parse_name_for_domains]
>(0x0200): name 'simecek.to...@sd-stc.cz' matched expression for domain '
>sd-stc.cz', user is simecek.tomas

Re: [Freeipa-users] named-pkcs11 fails to start on new replica [SOLVED]

[Bob Hinton]

On 14/07/2016 08:39, Martin Babinsky wrote:
> On 07/13/2016 09:56 PM, Bob Hinton wrote:
>> Hi,
>>
>> We are trying to create a new replica on RHEL 7.2
>>
>> This completes but named-pkcs11 fails to start -
>>
>>  systemctl status named-pkcs11.service
>> ● named-pkcs11.service - Berkeley Internet Name Domain (DNS) with native
>> PKCS#11
>>Loaded: loaded (/usr/lib/systemd/system/named-pkcs11.service;
>> disabled; vendor preset: disabled)
>>Active: failed (Result: exit-code) since Wed 2016-07-13 18:38:15 BST;
>> 51min ago
>>   Process: 25913 ExecStart=/usr/sbin/named-pkcs11 -u named $OPTIONS
>> (code=exited, status=1/FAILURE)
>>   Process: 25910 ExecStartPre=/bin/bash -c if [ !
>> "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -z
>> /etc/named.conf; else echo "Checking of zone files is disabled"; fi
>> (code=exited, status=0/SUCCESS)
>>
>> Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]: corporation.
>> Support and training for BIND 9 are
>> Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]: available at
>> https://www.isc.org/support
>> Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]:
>> 
>> Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]: adjusted limit on
>> open files from 4096 to 1048576
>> Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]: found 1 CPU,
>> using 1 worker thread
>> Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]: using 1 UDP
>> listener per interface
>> Jul 13 18:38:15 ipa001.mgmt.local systemd[1]: named-pkcs11.service:
>> control process exited, code=exited status=1
>> Jul 13 18:38:15 ipa001.mgmt.local systemd[1]: Failed to start Berkeley
>> Internet Name Domain (DNS) with native PKCS#11.
>> Jul 13 18:38:15 ipa001.mgmt.local systemd[1]: Unit named-pkcs11.service
>> entered failed state.
>> Jul 13 18:38:15 ipa001.mgmt.local systemd[1]: named-pkcs11.service
>> failed.
>>
>> # /usr/sbin/named-pkcs11 -d 9 -g
>> 13-Jul-2016 19:31:01.283 starting BIND 9.9.4-RedHat-9.9.4-29.el7_2.1
>> -d 9 -g
>> 13-Jul-2016 19:31:01.283 built with '--build=x86_64-redhat-linux-gnu'
>> '--host=x86_64-redhat-linux-gnu' '--program-prefix='
>> '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr'
>> '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc'
>> '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64'
>> '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib'
>> '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-libtool'
>> '--localstatedir=/var' '--enable-threads' '--enable-ipv6'
>> '--enable-filter-' '--enable-rrl' '--with-pic' '--disable-static'
>> '--disable-openssl-version-check' '--enable-exportlib'
>> '--with-export-libdir=/usr/lib64'
>> '--with-export-includedir=/usr/include'
>> '--includedir=/usr/include/bind9' '--enable-native-pkcs11'
>> '--with-pkcs11=/usr/lib64/pkcs11/libsofthsm2.so' '--with-dlopen=yes'
>> '--with-dlz-ldap=yes' '--with-dlz-postgres=yes' '--with-dlz-mysql=yes'
>> '--with-dlz-filesystem=yes' '--with-dlz-bdb=yes' '--with-gssapi=yes'
>> '--disable-isc-spnego' '--enable-fixed-rrset'
>> '--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets'
>> 'build_alias=x86_64-redhat-linux-gnu'
>> 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall
>> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
>> --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic'
>> 'LDFLAGS=-Wl,-z,relro ' 'CPPFLAGS= -DDIG_SIGCHASE'
>> 13-Jul-2016 19:31:01.283
>> 
>> 13-Jul-2016 19:31:01.284 BIND 9 is maintained by Internet Systems
>> Consortium,
>> 13-Jul-2016 19:31:01.284 Inc. (ISC), a non-profit 501(c)(3)
>> public-benefit
>> 13-Jul-2016 19:31:01.284 corporation.  Support and training for BIND
>> 9 are
>> 13-Jul-2016 19:31:01.284 available at https://www.isc.org/support
>> 13-Jul-2016 19:31:01.284
>> 
>> 13-Jul-2016 19:31:01.284 adjusted limit on open files from 4096 to
>> 1048576
>> 13-Jul-2016 19:31:01.284 found 1 CPU, using 1 worker thread
>> 13-Jul-2016 19:31:01.284 using 1 UDP listener per interface
>> 13-Jul-2016 19:31:01.284 using up to 4096 sockets
>> 13-Jul-2016 19:31:01.284 Registering DLZ_dlopen driver
>> 13-Jul-2016 19:31:01.284 Registering SDLZ driver 'dlopen'
>> 13-Jul-2016 19:31:01.284 Registering DLZ driver 'dlopen'
>> 13-Jul-2016 19:31:01.287 initializing DST: PKCS#11 initialization failed
>> 13-Jul-2016 19:31:01.287 exiting (due to fatal error)
>>
>> # tail -2 /var/log
>>
>> Jul 13 19:31:01 ipa001.mgmt.local named-pkcs11[27088]:
>> ObjectStore.cpp(59): Failed to enumerate object store in
>> /var/lib/softhsm/tokens/
>>
>> Jul 13 19:31:01 ipa001.mgmt.local named-pkcs11[27088]: SoftHSM.cpp(456):
>> Could not load the object store
>>
>> I've tried "ipa-server-upgrade" and
>>
>> mv /var/lib/ipa/dnssec/tokens /var/lib/ipa/dnssec/tokens-OLD
>>
>> ipa-dns-install
>>
>> But I haven't managed to 

Re: [Freeipa-users] HBAC and AD users

[Sumit Bose]

On Thu, Jul 14, 2016 at 11:47:41AM +1000, Lachlan Musicman wrote:
> Ok, I have some logs of sssd 1.13.0 not working. Same values as before:
> 
> FreeIPA server: Centos 7, ipa 4.2, API_VERSION 2.156
> 
> Installed Packages
> Name: ipa-server
> Arch: x86_64
> Version : 4.2.0
> Release : 15.0.1.el7.centos.17
> Size: 5.0 M
> Repo: installed
> >From repo   : updates
> Summary : The IPA authentication server
> 
> 
> Successfully joined in one way trust to AD.
> 
> Successfully have added hosts (Centos 7, sssd 1.13.0).
> 
> 
> [root@vmpr-linuxidm ~]# ipa hbacrule-find
> 
> 5 HBAC rules matched
> 
> 
>   Rule name: allow_all
>   User category: all
>   Host category: all
>   Service category: all
>   Description: Allow all users to access any host from any host
>   Enabled: FALSE
> 
> ...
> 
>   Rule name: ssh to galaxy
>   Service category: all
>   Description: Allows ssh to galaxy server
>   Enabled: TRUE
>   User Groups: ad_users
>   Hosts: papr-res-galaxy.unix.petermac.org.au
> 
> 
> 
> 
> With allow_all HBAC rule enabled, can login every time with
> 
> ssh user@ad_domain@unix_host
> 
> If I implement a HBAC rule "ssh to galaxy" as per above, with:
> 
> ad_users is a POSIX group with a GID. It has one member, the group
> 
> ad_external an external group with a single, external, member
> 
> pmc-res-ipaus...@petermac.org.au
> 
> which is an AD group containing all the users that should have access to
> the host.
> 
> 
> With allow_all disabled and "ssh to galaxy" enabled, some users can login
> and some can't. There is no discernable pattern that might explain why some
> are discriminated against.
> 
> Here is the test from the server:
> 
> [root@vmpr-linuxidm ~]# ipa hbactest --user=sandsjor...@petermac.org.au
> --host=papr-res-galaxy.unix.petermac.org.au --service=sshd
> 
> Access granted: True
> 
>   Matched rules: ssh to galaxy
>   Not matched rules: Computing Cluster
>   Not matched rules: FACS Computing
> 
> I've installed ipa-admintools on the host in question and got the same
> result.
> 
> To be on the safe side/tick all boxes, I have cleared the cache on the host
> in question:
> 
> systemctl stop sssd
> sss_cache -E
> systemctl start sssd
> 
> and confirmed success with a status check.
> 
> When the user tries to login, it fails.
> 
> Log is here:
> 
> http://dpaste.com/0VAFNPH
> 
> 
> The top is where the negotiating starts to the best of my knowledge.
> 
> The attempts fails, with no information that is useful to me:
> 
> 230 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
> [hbac_get_category] (0x0200): Category is set to 'all'.
> 231 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
> [hbac_thost_attrs_to_rule] (0x1000): Processing target hosts for rule [ssh
> to galaxy]
> 232 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
> [hbac_shost_attrs_to_rule] (0x0400): Processing source hosts for rule [ssh
> to galaxy]
> 233 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
> [hbac_eval_user_element] (0x1000): [3] groups for [
> sandsjor...@petermac.org.au]

According to the HBAC evaluation the user is a member of 3 groups. Is
this the expected number?

Can you check if 'id sandsjor...@petermac.org.au' returns the expected
list of groups on the client and the IPA server? (The client does not
talk to AD directly only to the IPA server, so if something is already
missing on the server it cannot be seen on the client as well).

Can you send me the SSSD cache file from the client
/var/lib/sss/db/cache_unix.petermac.org.au.ldb after the login attempt?
Since it might contain password hashes you might want to remove
lines with 'cachedPassword' before

bye,
Sumit


> 234 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
> [ipa_hbac_evaluate_rules] (0x0080): Access denied by HBAC rules
> 235 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
> [be_pam_handler_callback] (0x0100): Backend returned: (0, 6, )
> [Success (Permission denied)]
> 236 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
> [be_pam_handler_callback] (0x0100): Sending result [6][petermac.org.au]
> 237 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
> [be_pam_handler_callback] (0x0100): Sent result [6][petermac.org.au]
> 
> 
> Cheers
> L.
> 
> 
> --
> The most dangerous phrase in the language is, "We've always done it this
> way."
> 
> - Grace Hopper
> 
> On 12 July 2016 at 09:08, Lachlan Musicman  wrote:
> 
> > Alex, Sumit,
> >
> > Which log levels would you recommend for sssd to help debug this issue?
> >
> > We've been using 7, but I just realised that it's not an increasing scale
> > but bitmasked...
> >
> > cheers
> > L.
> >
> > --
> > The most dangerous phrase in the language is, "We've always done it this
> > way."
> >
> > - Grace Hopper
> >
> > On 11 July 2016 at 17:15, Sumit Bose  wrote:

Re: [Freeipa-users] named-pkcs11 fails to start on new replica

[Martin Babinsky]

On 07/13/2016 09:56 PM, Bob Hinton wrote:

Hi,

We are trying to create a new replica on RHEL 7.2

This completes but named-pkcs11 fails to start -

 systemctl status named-pkcs11.service
● named-pkcs11.service - Berkeley Internet Name Domain (DNS) with native
PKCS#11
   Loaded: loaded (/usr/lib/systemd/system/named-pkcs11.service;
disabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Wed 2016-07-13 18:38:15 BST;
51min ago
  Process: 25913 ExecStart=/usr/sbin/named-pkcs11 -u named $OPTIONS
(code=exited, status=1/FAILURE)
  Process: 25910 ExecStartPre=/bin/bash -c if [ !
"$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -z
/etc/named.conf; else echo "Checking of zone files is disabled"; fi
(code=exited, status=0/SUCCESS)

Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]: corporation.
Support and training for BIND 9 are
Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]: available at
https://www.isc.org/support
Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]:

Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]: adjusted limit on
open files from 4096 to 1048576
Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]: found 1 CPU,
using 1 worker thread
Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]: using 1 UDP
listener per interface
Jul 13 18:38:15 ipa001.mgmt.local systemd[1]: named-pkcs11.service:
control process exited, code=exited status=1
Jul 13 18:38:15 ipa001.mgmt.local systemd[1]: Failed to start Berkeley
Internet Name Domain (DNS) with native PKCS#11.
Jul 13 18:38:15 ipa001.mgmt.local systemd[1]: Unit named-pkcs11.service
entered failed state.
Jul 13 18:38:15 ipa001.mgmt.local systemd[1]: named-pkcs11.service failed.

# /usr/sbin/named-pkcs11 -d 9 -g
13-Jul-2016 19:31:01.283 starting BIND 9.9.4-RedHat-9.9.4-29.el7_2.1 -d 9 -g
13-Jul-2016 19:31:01.283 built with '--build=x86_64-redhat-linux-gnu'
'--host=x86_64-redhat-linux-gnu' '--program-prefix='
'--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr'
'--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc'
'--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64'
'--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib'
'--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-libtool'
'--localstatedir=/var' '--enable-threads' '--enable-ipv6'
'--enable-filter-' '--enable-rrl' '--with-pic' '--disable-static'
'--disable-openssl-version-check' '--enable-exportlib'
'--with-export-libdir=/usr/lib64'
'--with-export-includedir=/usr/include'
'--includedir=/usr/include/bind9' '--enable-native-pkcs11'
'--with-pkcs11=/usr/lib64/pkcs11/libsofthsm2.so' '--with-dlopen=yes'
'--with-dlz-ldap=yes' '--with-dlz-postgres=yes' '--with-dlz-mysql=yes'
'--with-dlz-filesystem=yes' '--with-dlz-bdb=yes' '--with-gssapi=yes'
'--disable-isc-spnego' '--enable-fixed-rrset'
'--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets'
'build_alias=x86_64-redhat-linux-gnu'
'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic'
'LDFLAGS=-Wl,-z,relro ' 'CPPFLAGS= -DDIG_SIGCHASE'
13-Jul-2016 19:31:01.283

13-Jul-2016 19:31:01.284 BIND 9 is maintained by Internet Systems
Consortium,
13-Jul-2016 19:31:01.284 Inc. (ISC), a non-profit 501(c)(3) public-benefit
13-Jul-2016 19:31:01.284 corporation.  Support and training for BIND 9 are
13-Jul-2016 19:31:01.284 available at https://www.isc.org/support
13-Jul-2016 19:31:01.284

13-Jul-2016 19:31:01.284 adjusted limit on open files from 4096 to 1048576
13-Jul-2016 19:31:01.284 found 1 CPU, using 1 worker thread
13-Jul-2016 19:31:01.284 using 1 UDP listener per interface
13-Jul-2016 19:31:01.284 using up to 4096 sockets
13-Jul-2016 19:31:01.284 Registering DLZ_dlopen driver
13-Jul-2016 19:31:01.284 Registering SDLZ driver 'dlopen'
13-Jul-2016 19:31:01.284 Registering DLZ driver 'dlopen'
13-Jul-2016 19:31:01.287 initializing DST: PKCS#11 initialization failed
13-Jul-2016 19:31:01.287 exiting (due to fatal error)

# tail -2 /var/log

Jul 13 19:31:01 ipa001.mgmt.local named-pkcs11[27088]:
ObjectStore.cpp(59): Failed to enumerate object store in
/var/lib/softhsm/tokens/

Jul 13 19:31:01 ipa001.mgmt.local named-pkcs11[27088]: SoftHSM.cpp(456):
Could not load the object store

I've tried "ipa-server-upgrade" and

mv /var/lib/ipa/dnssec/tokens /var/lib/ipa/dnssec/tokens-OLD

ipa-dns-install

But I haven't managed to fix it.

Using "ipactl start -f" means the rest of the ipa services seem to work
properly, but without named.

Is there a way to fix the named issue or is it much simpler to
disconnect the replica, uninstall it and start again ?

Thanks

Bob Hinton





Hi Bob,

If your SElinux is in enforcing mode I would check for AVCs, maybe the 
token 

Re: [Freeipa-users] sudo - differences between Centos 6.5 and Centos 7.0?

[Lukas Slebodnik]

On (13/07/16 10:32), Danila Ladner wrote:
>Update to this one:
>It has been running smoothly on 6.5
>
>[root@dev-zlei.sec1 ~]# cat /etc/redhat-release
>CentOS release 6.5 (Final)
>
>[root@dev-zlei.sec1 ~]# rpm -qa | grep sssd
>sssd-client-1.12.4-47.el6.x86_64
>sssd-ldap-1.12.4-47.el6.x86_64
>sssd-ad-1.12.4-47.el6.x86_64
>python-sssdconfig-1.12.4-47.el6.noarch
>sssd-common-1.12.4-47.el6.x86_64
>sssd-proxy-1.12.4-47.el6.x86_64
>sssd-common-pac-1.12.4-47.el6.x86_64
>sssd-krb5-1.12.4-47.el6.x86_64
>sssd-ipa-1.12.4-47.el6.x86_64
>sssd-krb5-common-1.12.4-47.el6.x86_64
>sssd-1.12.4-47.el6.x86_64
>
+1 for latest sssd even on CentOS 6.5.

If you have a problem with 1.12 (from 6.7)
then we can look into log files.
Because there is a still a chance that oyu just hit
a bug in 1.11 which is solved in 1.12

If it will not work then please provide
sssd.conf + log files with high debug_level sssd_sudo.log
and sssd_$domain.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