Re: [Freeipa-users] Partial replica

[Tomas Babej]

On 09/15/2015 05:14 PM, Nicola Canepa wrote:
> Hello list.
> I'm trying to make a test deploy of FreeIPA, and I was wondering if it
> is possible to authenticate remote sites via LDAP by havong a partial
> replica based on saome filter (maybe a group, an attribute or similar).
> 
> Sorry if this is a silly question, but I am trying to explore the
> possibilities that I could have to slowly replace local authentications
> spread in various sites by having a central store (backed by FreeIPA)
> and many partial replicas which would contain what now I have in RADIUS
> or other authentication sources.
> 
> Thank you for any advice or pointer you can give to me.
> 
> Nicola
> 

Hello!

Short answer is that FreeIPA does not support filter-based partial
replication.

AFAIK, 389 can do fractional replication, which can exclude certain
attributes from being replicated (and hence lower the replication
traffic), but I gather that will not help in your use case. See
nsds5replicatedattributelist and nsds5replicatedattributelisttotal
attributes of the replication agreement, if interested.

Tomas

-- 
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] Creating A Subordinate Certificate Authortity in FreeIPA

[Silver Sky Soft Services, Inc.]

Hi Fraser,
Thanks. I actually looked at your proposal. It certainly makes it
easier. But hopefully the info we put in will help others in need.

The EV bar - we are finishing up on a detailed analysis. In summary,
its actually not possible to get green bar without recompiling
Mozilla/Chrome (which makes it an impractical solution to work with
for anything but very small networks). IE on the other hand is simpler
if you have AD environment.

-Kiran

On Mon, Sep 21, 2015 at 7:54 PM, Fraser Tweedale  wrote:
> On Mon, Sep 21, 2015 at 06:44:30PM -0700, Silver Sky Soft Services, Inc. 
> wrote:
>> Hi all,
>> Recently we needed to create a subordinate CA in FreeIPA and
>> conveniently used the certificate profile feature in 4.2.0. For
>> benefit of others, I have documented this in our blog,
>>
>> http://silverskysoft.com/open-stack-xwrpr/2015/09/creating-a-subordinate-certificate-authortity-in-freeipa/
>>
>> Any comments are appreciated.
>>
>> Summary of the profile is:
>> *) Set the CA flag set to true
>> *) Set the appropriate Key Usage constraint.
>>
>> policyset.caSubCertSet.5.constraint.params.basicConstraintsIsCA=true
>> policyset.caSubCertSet.5.constraint.params.basicConstraintsMinPathLen=0
>> policyset.caSubCertSet.5.constraint.params.basicConstraintsMaxPathLen=0
>> policyset.caSubCertSet.5.default.class_id=basicConstraintsExtDefaultImpl
>> policyset.caSubCertSet.5.default.name=Basic Constraints Extension Default
>> policyset.caSubCertSet.5.default.params.basicConstraintsCritical=true
>> policyset.caSubCertSet.5.default.params.basicConstraintsIsCA=true
>> policyset.caSubCertSet.5.default.params.basicConstraintsPathLen=0
>> policyset.caSubCertSet.6.constraint.class_id=keyUsageExtConstraintImpl
>> policyset.caSubCertSet.6.constraint.name=Key Usage Extension Constraint
>> policyset.caSubCertSet.6.constraint.params.keyUsageCritical=true
>> policyset.caSubCertSet.6.constraint.params.keyUsageDigitalSignature=true
>> policyset.caSubCertSet.6.constraint.params.keyUsageNonRepudiation=true
>> policyset.caSubCertSet.6.constraint.params.keyUsageDataEncipherment=false
>> policyset.caSubCertSet.6.constraint.params.keyUsageKeyEncipherment=false
>> policyset.caSubCertSet.6.constraint.params.keyUsageKeyAgreement=false
>> policyset.caSubCertSet.6.constraint.params.keyUsageKeyCertSign=true
>> policyset.caSubCertSet.6.constraint.params.keyUsageCrlSign=true
>> policyset.caSubCertSet.6.constraint.params.keyUsageEncipherOnly=false
>> policyset.caSubCertSet.6.constraint.params.keyUsageDecipherOnly=false
>>
>> We have verified the certs issued with Sub-CA are accepted in browsers
>> where only the Root CA is set as trusted.
>>
>> -Kiran
>>
> Thank you for sharing, Kiran!
>
> A future version of FreeIPA will support creating sub-CAs via a
> native plugin and allow specifying the desired issuer as an argument
> to `ipa cert-request' and `ipa-getcert request'.
>
> Regarding EV: the list of supported EV policies is maintained by
> browser vendors and validation includes matching the policy OID with
> the expected issuer.  Accordingly, even with the right Dogtag
> profile you would have to modify the browser (or, possibly, some
> configuration that is read by the browser) to attain the green bar.
> It is probably not worth the effort :)
>
> Cheers,
> Fraser

-- 
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] otp issue: can't log in with password+otp

[Duncan McNaught]

Dear freeipa-users,

I'm having an issue with otp in freeipa. I can set up the service as
described in the blog post for TOTP or HOTP, and sync the token fine.
When I try to login to the admin tools or an ipa-managed client (with
) , I get a password incorrect message.
Here are some more details:
https://github.com/adelton/docker-freeipa/issues/34
Can anyone help me to debug/get this working?

Thanks
--Duncan
-- 
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] last step in retiring old RHEL 6 (IPA 3.0.0) servers

[Craig White]

-Original Message-
From: Petr Vobornik [mailto:pvobo...@redhat.com] 
Sent: Friday, September 18, 2015 1:44 AM
To: Craig White; Martin Kosek; freeipa-users@redhat.com; Jan Cholasta
Subject: Re: [Freeipa-users] last step in retiring old RHEL 6 (IPA 3.0.0) 
servers

On 09/17/2015 06:19 PM, Craig White wrote:
> -Original Message-
> From: Petr Vobornik [mailto:pvobo...@redhat.com]
> Sent: Thursday, September 17, 2015 4:59 AM
> To: Martin Kosek; Craig White; freeipa-users@redhat.com; Jan Cholasta
> Subject: Re: [Freeipa-users] last step in retiring old RHEL 6 (IPA 
> 3.0.0) servers
>
>>> What's the trick to get rid of an old, discontinued 'master' ?
>>>
>>> Craig White
>>
>> Quickly looking at ipa-replica-manage code, the del command will end 
>> if there is no RUV. So it seems that in some of your previous RUV was 
>> deleted, but server record was not.
>>
>> What does
>> # ipa-replica-manage list-ruv
>> show?
>>
>> Petr or Honza, is the only option here to
>> 1) Use ldapdelete to delete the master record in cn=masters as a 
>> hotfix for this issue
>
> It will fix the replica manage output but replica cleanup does more things 
> than just a removal of master entry. It also:
>   deletes services of the host

This part could be done in web ui - check for 
/ipa1.stt.local@STT.LOCAL

where  is usually DNS, HTTP and ldap


The webui also shows a dogtag/ipa1.stt.local@STT.LOCAL but no other dogtag 
URL's (like the new master). Is it no longer needed or should it be changed to 
the new CA-master?


>   removes s4u2proxy configuration
>   removes some ACIs
>
> More info:
> https://git.fedorahosted.org/cgit/freeipa.git/tree/ipaserver/install/r
> eplication.py#n1185
>
>
>> 2) File a ticket to avoid get_ruv function exit the whole "del"
>> command when --force is in play to fix this long-term
>
> https://fedorahosted.org/freeipa/ticket/5307
> 
> OK - I think I see the LDAP entries and just wanting confirmation 
> before I do great harm  :-)
>
> Dn: cn=ipa1.stt.local,cn=masters,cn=ipa,cn=etc,dc=stt,dc=local

yes


If by ipa1_ETC you mean (assuming that your realm is STT.LOCAL):
> Dn: cn=ipa-http-delegation,cn=s4u2proxy,cn=etc,dc=stt,dc=local - 
> attribute memberPrincipal ipa1_ETC

HTTP/ipa1.stt.local@STT.LOCAL

> Dn: cn=ipa-ldap-delegation-targets,cn=s4u2proxy,cn=etc,dc=stt,dc=local 
> - attribute memberPrincipal ipa1_ETC

ldap/ipa1.stt.local@STT.LOCAL



>
> The one DN and the 2 attributes are what I should delete to get rid of this 
> dead master?
>
> Rummaging around, I do see other hanging chads (pardon the election season 
> humor)...
>
> DN: dnaHostname ipa1.stt.local + 
> 0,cn=posix-ids,cn=dna,cn=etc,dc=stt,dc=local (that is apparently 
> 'dnaPortNum 0 and dnaSecurePortNum 636)
> DN: dnaHostname ipa1.stt.local + 
> 389,cn=posix-ids,cn=dna,cn=etc,dc=stt,dc=local (that is apparently 
> 'dnaPortNum 389 and dnaSecurePortNum 636)
>
> And if  were to delete the first one, there wouldn't be any entries pointing 
> to port '0' but that just looks strange to me anyway. If I delete both the 
> above, then all that is left is just the 2 new RHEL 7 IPA/iDM servers on 
> ports 389/636 which seems right to me.

Check if the DNA range configuration for the deleted master does contain dna 
RemainingValues other than 0. In that case you might want to check DNA 
configuration of other masters to be sure that other master can issue posix 
numbers.

DNA ranges could be also configured using ipa-replica-manage.
-

Yes, the other servers are there and seem to handle the right stuff

-

>
> If there are actual ACI's to edit, I am afraid I don't have a tool to do that 
> very easily.

Could  be seen e.g., when browsing LDAP structure in Apache Directory studio as 
Directory Manager. It's 'aci' attribute of entry 
cn=masters,cn=ipa,cn=etc,$SUFFIX

There should be two which contain the deleted replica hostname. One has name 
"Read IPA Masters" the other "Modify IPA Masters".


Not sure I understand.

There are entries for the 3 servers in question
Ipa1, ipa3, ipa4 but in cn=masters,cn=ipa,cn=etc,$SUFFIX there isn't anything 
(i.e. attributes) that are called IPA Masters or Modify IPA Masters under any 
of them.

Thanks


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

[Freeipa-users] Creating A Subordinate Certificate Authortity in FreeIPA

[Silver Sky Soft Services, Inc.]

Hi all,
Recently we needed to create a subordinate CA in FreeIPA and
conveniently used the certificate profile feature in 4.2.0. For
benefit of others, I have documented this in our blog,

http://silverskysoft.com/open-stack-xwrpr/2015/09/creating-a-subordinate-certificate-authortity-in-freeipa/

Any comments are appreciated.

Summary of the profile is:
*) Set the CA flag set to true
*) Set the appropriate Key Usage constraint.

policyset.caSubCertSet.5.constraint.params.basicConstraintsIsCA=true
policyset.caSubCertSet.5.constraint.params.basicConstraintsMinPathLen=0
policyset.caSubCertSet.5.constraint.params.basicConstraintsMaxPathLen=0
policyset.caSubCertSet.5.default.class_id=basicConstraintsExtDefaultImpl
policyset.caSubCertSet.5.default.name=Basic Constraints Extension Default
policyset.caSubCertSet.5.default.params.basicConstraintsCritical=true
policyset.caSubCertSet.5.default.params.basicConstraintsIsCA=true
policyset.caSubCertSet.5.default.params.basicConstraintsPathLen=0
policyset.caSubCertSet.6.constraint.class_id=keyUsageExtConstraintImpl
policyset.caSubCertSet.6.constraint.name=Key Usage Extension Constraint
policyset.caSubCertSet.6.constraint.params.keyUsageCritical=true
policyset.caSubCertSet.6.constraint.params.keyUsageDigitalSignature=true
policyset.caSubCertSet.6.constraint.params.keyUsageNonRepudiation=true
policyset.caSubCertSet.6.constraint.params.keyUsageDataEncipherment=false
policyset.caSubCertSet.6.constraint.params.keyUsageKeyEncipherment=false
policyset.caSubCertSet.6.constraint.params.keyUsageKeyAgreement=false
policyset.caSubCertSet.6.constraint.params.keyUsageKeyCertSign=true
policyset.caSubCertSet.6.constraint.params.keyUsageCrlSign=true
policyset.caSubCertSet.6.constraint.params.keyUsageEncipherOnly=false
policyset.caSubCertSet.6.constraint.params.keyUsageDecipherOnly=false

We have verified the certs issued with Sub-CA are accepted in browsers
where only the Root CA is set as trusted.

-Kiran

-- 
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] Creating A Subordinate Certificate Authortity in FreeIPA

[Fraser Tweedale]

On Mon, Sep 21, 2015 at 06:44:30PM -0700, Silver Sky Soft Services, Inc. wrote:
> Hi all,
> Recently we needed to create a subordinate CA in FreeIPA and
> conveniently used the certificate profile feature in 4.2.0. For
> benefit of others, I have documented this in our blog,
> 
> http://silverskysoft.com/open-stack-xwrpr/2015/09/creating-a-subordinate-certificate-authortity-in-freeipa/
> 
> Any comments are appreciated.
> 
> Summary of the profile is:
> *) Set the CA flag set to true
> *) Set the appropriate Key Usage constraint.
> 
> policyset.caSubCertSet.5.constraint.params.basicConstraintsIsCA=true
> policyset.caSubCertSet.5.constraint.params.basicConstraintsMinPathLen=0
> policyset.caSubCertSet.5.constraint.params.basicConstraintsMaxPathLen=0
> policyset.caSubCertSet.5.default.class_id=basicConstraintsExtDefaultImpl
> policyset.caSubCertSet.5.default.name=Basic Constraints Extension Default
> policyset.caSubCertSet.5.default.params.basicConstraintsCritical=true
> policyset.caSubCertSet.5.default.params.basicConstraintsIsCA=true
> policyset.caSubCertSet.5.default.params.basicConstraintsPathLen=0
> policyset.caSubCertSet.6.constraint.class_id=keyUsageExtConstraintImpl
> policyset.caSubCertSet.6.constraint.name=Key Usage Extension Constraint
> policyset.caSubCertSet.6.constraint.params.keyUsageCritical=true
> policyset.caSubCertSet.6.constraint.params.keyUsageDigitalSignature=true
> policyset.caSubCertSet.6.constraint.params.keyUsageNonRepudiation=true
> policyset.caSubCertSet.6.constraint.params.keyUsageDataEncipherment=false
> policyset.caSubCertSet.6.constraint.params.keyUsageKeyEncipherment=false
> policyset.caSubCertSet.6.constraint.params.keyUsageKeyAgreement=false
> policyset.caSubCertSet.6.constraint.params.keyUsageKeyCertSign=true
> policyset.caSubCertSet.6.constraint.params.keyUsageCrlSign=true
> policyset.caSubCertSet.6.constraint.params.keyUsageEncipherOnly=false
> policyset.caSubCertSet.6.constraint.params.keyUsageDecipherOnly=false
> 
> We have verified the certs issued with Sub-CA are accepted in browsers
> where only the Root CA is set as trusted.
> 
> -Kiran
> 
Thank you for sharing, Kiran!

A future version of FreeIPA will support creating sub-CAs via a
native plugin and allow specifying the desired issuer as an argument
to `ipa cert-request' and `ipa-getcert request'.

Regarding EV: the list of supported EV policies is maintained by
browser vendors and validation includes matching the policy OID with
the expected issuer.  Accordingly, even with the right Dogtag
profile you would have to modify the browser (or, possibly, some
configuration that is read by the browser) to attain the green bar.
It is probably not worth the effort :)

Cheers,
Fraser

-- 
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] Another CentOS 6.x to CentOS 7.1 migration question

[Robert Story]

I've followed the migration document
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/migrating-ipa-proc.html
almost to the end.

I'm at step 10, which stops everything on the old . My concern is all
the installed servers that are pointing at the old system. That host name
is hardcoded in sssd.conf all over my network, and we rely on freeIPA for
centralized user management and ssh keys.

My original system was auth.example, and the new one is auth-2.example. Is
it safe to make auth.example a CNAME to auth-2.example? Or will something
somewhere break if the ip address changes (and is pointing at a newer
version of freeIP)?


Robert

-- 
Senior Software Engineer @ Parsons


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

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

[Andy Thompson]

> 
> On Thu, Sep 17, 2015 at 11:42:54AM +, Andy Thompson wrote:
> > I've narrowed it down a bit doing some testing.  The sudo rules work when
> I remove the user group restriction from them.  My sudo rules all have my ad
> groups in the rule
> >
> >   Rule name: ad_linux_admins
> >   Enabled: TRUE
> >   Host category: all
> >   Command category: all
> >   RunAs User category: all
> >   RunAs Group category: all
> >   User Groups: ad_linux_admins  <- if I remove this then the rule gets
> applied
> 
> Nice catch. Is the group visible after you login and run id?
> 
> What is the exact IPA server version?

Ok I also figured out if I rename my AD groups to match my IPA groups then the 
sudo rules are applied.  

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

%@   "sudo commands"

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

On a server running sssd 1.12 that rule works, but does not work if I remove 
the .  And none of the IPA sudo rules work.  So something changed 
with the domain suffix between versions it would appear.

They key to making the IPA sudo rules work in 1.12 is to remove the 
default_domain_suffix setting in the sssd.conf, but that's not an option in my 
environment. 

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

-andy




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

Re: [Freeipa-users] SSSD client (amazon linux) + IPA server (Redhat)

[Gustavo Mateus]

I used compat because that is what ipa-advise provided me. I did not pay
attention to that part.
And yes, that did the trick :)

Thank you very much
Gustavo

On Sun, Sep 20, 2015 at 8:51 AM, Jakub Hrozek  wrote:

> On Sat, Sep 19, 2015 at 07:47:55PM +0300, Alexander Bokovoy wrote:
> > On Sat, 19 Sep 2015, Jakub Hrozek wrote:
> > >
> > >>On 18 Sep 2015, at 19:17, Gustavo Mateus 
> wrote:
> > >>
> > >>That only shows this:
> > >>
> > >># extended LDIF
> > >>#
> > >># LDAPv3
> > >># base 

Re: [Freeipa-users] SSSD client (amazon linux) + IPA server (Redhat)

[Jakub Hrozek]

On Mon, Sep 21, 2015 at 10:40:07PM +0300, Alexander Bokovoy wrote:
> At this point I'd suggest you to investigate yourself and contact Amazon
> support for finding out exactly what is happening there.

It would be nice if Amazon actually packaged all the functionality RHEL
packages for several years :-)

But maybe there are some issues preventing them -- filing a support case
and asking them might go a long way. I'm sure if Amazon approached us on
this (or the -devel) list we'd be glad to work with them on any
technical issues..

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

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

[Andy Thompson]

> -Original Message-
> From: Jakub Hrozek [mailto:jhro...@redhat.com]
> Sent: Monday, September 21, 2015 3:29 PM
> To: Andy Thompson 
> Cc: freeipa-users@redhat.com; pbrez...@redhat.com
> Subject: Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo
> 
> On Mon, Sep 21, 2015 at 02:22:54PM +, Andy Thompson wrote:
> > >
> > > On Thu, Sep 17, 2015 at 11:42:54AM +, Andy Thompson wrote:
> > > > I've narrowed it down a bit doing some testing.  The sudo rules
> > > > work when
> > > I remove the user group restriction from them.  My sudo rules all
> > > have my ad groups in the rule
> > > >
> > > >   Rule name: ad_linux_admins
> > > >   Enabled: TRUE
> > > >   Host category: all
> > > >   Command category: all
> > > >   RunAs User category: all
> > > >   RunAs Group category: all
> > > >   User Groups: ad_linux_admins  <- if I remove this then the rule
> > > > gets
> > > applied
> > >
> > > Nice catch. Is the group visible after you login and run id?
> > >
> > > What is the exact IPA server version?
> >
> > Ok I also figured out if I rename my AD groups to match my IPA groups then
> the sudo rules are applied.
> >
> > I tested a couple things though, if I put a rule in the local sudoers
> > file on a server running sssd 1.11
> >
> > %@   "sudo commands"
> >
> > That rule was not applied.  If I remove the  then the rule got
> applied.
> >
> > On a server running sssd 1.12 that rule works, but does not work if I
> remove the .  And none of the IPA sudo rules work.  So
> something changed with the domain suffix between versions it would
> appear.
> >
> > They key to making the IPA sudo rules work in 1.12 is to remove the
> default_domain_suffix setting in the sssd.conf, but that's not an option in my
> environment.
> >
> > So all the moving parts together, it appears that having AD groups
> > with a different name than the IPA groups in conjunction with the
> > default_domain_suffix setting breaks things right now in 1.12.
> > Appears since I renamed the ad group to match then the rule without a
> > domain suffix will get matched now
> 
> Hello Andy,
> 
> I'm sorry for the constant delays, but I was busy with some trust-related 
> fixes
> lately.
> 
> Did you have a chance to confirm that just swapping sssd /on the client/
> while keeping the same version on the server fixes the issue for you?
> 
> Pavel (CC), can you help me out here, please? I have the setup ready on my
> machine, so tomorrow we can take a look and experiment (I can give you
> access to my environment via tmate maybe..), but I wasn't able to reproduce
> the issue locally yet.

It's fine I understand the backlog.  

I was not able to backrev the sssd due to dependency issues.  I tried 
downgrading all the dependencies and got in a loop and stopped trying.  Are 
there any tricks you can think of to downgrade the sssd cleanly?

-andy


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

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

[Jakub Hrozek]

On Mon, Sep 21, 2015 at 07:39:01PM +, Andy Thompson wrote:
> > -Original Message-
> > From: Jakub Hrozek [mailto:jhro...@redhat.com]
> > Sent: Monday, September 21, 2015 3:29 PM
> > To: Andy Thompson 
> > Cc: freeipa-users@redhat.com; pbrez...@redhat.com
> > Subject: Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo
> > 
> > On Mon, Sep 21, 2015 at 02:22:54PM +, Andy Thompson wrote:
> > > >
> > > > On Thu, Sep 17, 2015 at 11:42:54AM +, Andy Thompson wrote:
> > > > > I've narrowed it down a bit doing some testing.  The sudo rules
> > > > > work when
> > > > I remove the user group restriction from them.  My sudo rules all
> > > > have my ad groups in the rule
> > > > >
> > > > >   Rule name: ad_linux_admins
> > > > >   Enabled: TRUE
> > > > >   Host category: all
> > > > >   Command category: all
> > > > >   RunAs User category: all
> > > > >   RunAs Group category: all
> > > > >   User Groups: ad_linux_admins  <- if I remove this then the rule
> > > > > gets
> > > > applied
> > > >
> > > > Nice catch. Is the group visible after you login and run id?
> > > >
> > > > What is the exact IPA server version?
> > >
> > > Ok I also figured out if I rename my AD groups to match my IPA groups then
> > the sudo rules are applied.
> > >
> > > I tested a couple things though, if I put a rule in the local sudoers
> > > file on a server running sssd 1.11
> > >
> > > %@   "sudo commands"
> > >
> > > That rule was not applied.  If I remove the  then the rule got
> > applied.
> > >
> > > On a server running sssd 1.12 that rule works, but does not work if I
> > remove the .  And none of the IPA sudo rules work.  So
> > something changed with the domain suffix between versions it would
> > appear.
> > >
> > > They key to making the IPA sudo rules work in 1.12 is to remove the
> > default_domain_suffix setting in the sssd.conf, but that's not an option in 
> > my
> > environment.
> > >
> > > So all the moving parts together, it appears that having AD groups
> > > with a different name than the IPA groups in conjunction with the
> > > default_domain_suffix setting breaks things right now in 1.12.
> > > Appears since I renamed the ad group to match then the rule without a
> > > domain suffix will get matched now
> > 
> > Hello Andy,
> > 
> > I'm sorry for the constant delays, but I was busy with some trust-related 
> > fixes
> > lately.
> > 
> > Did you have a chance to confirm that just swapping sssd /on the client/
> > while keeping the same version on the server fixes the issue for you?
> > 
> > Pavel (CC), can you help me out here, please? I have the setup ready on my
> > machine, so tomorrow we can take a look and experiment (I can give you
> > access to my environment via tmate maybe..), but I wasn't able to reproduce
> > the issue locally yet.
> 
> It's fine I understand the backlog.  
> 
> I was not able to backrev the sssd due to dependency issues.  I tried 
> downgrading all the dependencies and got in a loop and stopped trying.  Are 
> there any tricks you can think of to downgrade the sssd cleanly?
> 
> -andy
> 

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

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

Re: [Freeipa-users] SSSD client (amazon linux) + IPA server (Redhat)

[Alexander Bokovoy]

On Mon, 21 Sep 2015, Jakub Hrozek wrote:

On Mon, Sep 21, 2015 at 10:40:07PM +0300, Alexander Bokovoy wrote:

At this point I'd suggest you to investigate yourself and contact Amazon
support for finding out exactly what is happening there.


It would be nice if Amazon actually packaged all the functionality RHEL
packages for several years :-)

But maybe there are some issues preventing them -- filing a support case
and asking them might go a long way. I'm sure if Amazon approached us on
this (or the -devel) list we'd be glad to work with them on any
technical issues..

According to Amazon, they have issues with packaging Samba. I'd let them
to respond themselves, given they are the only ones who can respond on
why they are so insisting on not packaging Samba while providing one of
key infrastructure parts of AWS via Samba AD.

https://forums.aws.amazon.com/thread.jspa?threadID=164971
--
/ 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] rhel 6.7 upgrade - sssd/sudo

[Andy Thompson]

> On Mon, Sep 21, 2015 at 07:39:01PM +, Andy Thompson wrote:
> > > -Original Message-
> > > From: Jakub Hrozek [mailto:jhro...@redhat.com]
> > > Sent: Monday, September 21, 2015 3:29 PM
> > > To: Andy Thompson 
> > > Cc: freeipa-users@redhat.com; pbrez...@redhat.com
> > > Subject: Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo
> > >
> > > On Mon, Sep 21, 2015 at 02:22:54PM +, Andy Thompson wrote:
> > > > >
> > > > > On Thu, Sep 17, 2015 at 11:42:54AM +, Andy Thompson wrote:
> > > > > > I've narrowed it down a bit doing some testing.  The sudo
> > > > > > rules work when
> > > > > I remove the user group restriction from them.  My sudo rules
> > > > > all have my ad groups in the rule
> > > > > >
> > > > > >   Rule name: ad_linux_admins
> > > > > >   Enabled: TRUE
> > > > > >   Host category: all
> > > > > >   Command category: all
> > > > > >   RunAs User category: all
> > > > > >   RunAs Group category: all
> > > > > >   User Groups: ad_linux_admins  <- if I remove this then the
> > > > > > rule gets
> > > > > applied
> > > > >
> > > > > Nice catch. Is the group visible after you login and run id?
> > > > >
> > > > > What is the exact IPA server version?
> > > >
> > > > Ok I also figured out if I rename my AD groups to match my IPA
> > > > groups then
> > > the sudo rules are applied.
> > > >
> > > > I tested a couple things though, if I put a rule in the local
> > > > sudoers file on a server running sssd 1.11
> > > >
> > > > %@   "sudo commands"
> > > >
> > > > That rule was not applied.  If I remove the  then the
> > > > rule got
> > > applied.
> > > >
> > > > On a server running sssd 1.12 that rule works, but does not work
> > > > if I
> > > remove the .  And none of the IPA sudo rules work.  So
> > > something changed with the domain suffix between versions it would
> > > appear.
> > > >
> > > > They key to making the IPA sudo rules work in 1.12 is to remove
> > > > the
> > > default_domain_suffix setting in the sssd.conf, but that's not an
> > > option in my environment.
> > > >
> > > > So all the moving parts together, it appears that having AD groups
> > > > with a different name than the IPA groups in conjunction with the
> > > > default_domain_suffix setting breaks things right now in 1.12.
> > > > Appears since I renamed the ad group to match then the rule
> > > > without a domain suffix will get matched now
> > >
> > > Hello Andy,
> > >
> > > I'm sorry for the constant delays, but I was busy with some
> > > trust-related fixes lately.
> > >
> > > Did you have a chance to confirm that just swapping sssd /on the
> > > client/ while keeping the same version on the server fixes the issue for
> you?
> > >
> > > Pavel (CC), can you help me out here, please? I have the setup ready
> > > on my machine, so tomorrow we can take a look and experiment (I can
> > > give you access to my environment via tmate maybe..), but I wasn't
> > > able to reproduce the issue locally yet.
> >
> > It's fine I understand the backlog.
> >
> > I was not able to backrev the sssd due to dependency issues.  I tried
> downgrading all the dependencies and got in a loop and stopped trying.  Are
> there any tricks you can think of to downgrade the sssd cleanly?
> >
> > -andy
> >
> 
> What failures are you getting? I normally just download all \*sss\* packages
> and then downgrade with rpm -U --oldpackage.


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

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

I get multilib errors with libsss_idmap.  

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

-andy


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

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

[Jakub Hrozek]

On Mon, Sep 21, 2015 at 02:22:54PM +, Andy Thompson wrote:
> > 
> > On Thu, Sep 17, 2015 at 11:42:54AM +, Andy Thompson wrote:
> > > I've narrowed it down a bit doing some testing.  The sudo rules work when
> > I remove the user group restriction from them.  My sudo rules all have my ad
> > groups in the rule
> > >
> > >   Rule name: ad_linux_admins
> > >   Enabled: TRUE
> > >   Host category: all
> > >   Command category: all
> > >   RunAs User category: all
> > >   RunAs Group category: all
> > >   User Groups: ad_linux_admins  <- if I remove this then the rule gets
> > applied
> > 
> > Nice catch. Is the group visible after you login and run id?
> > 
> > What is the exact IPA server version?
> 
> Ok I also figured out if I rename my AD groups to match my IPA groups then 
> the sudo rules are applied.  
> 
> I tested a couple things though, if I put a rule in the local sudoers file on 
> a server running sssd 1.11 
> 
> %@   "sudo commands"
> 
> That rule was not applied.  If I remove the  then the rule got 
> applied.  
> 
> On a server running sssd 1.12 that rule works, but does not work if I remove 
> the .  And none of the IPA sudo rules work.  So something changed 
> with the domain suffix between versions it would appear.
> 
> They key to making the IPA sudo rules work in 1.12 is to remove the 
> default_domain_suffix setting in the sssd.conf, but that's not an option in 
> my environment. 
> 
> So all the moving parts together, it appears that having AD groups with a 
> different name than the IPA groups in conjunction with the 
> default_domain_suffix setting breaks things right now in 1.12.  Appears since 
> I renamed the ad group to match then the rule without a domain suffix will 
> get matched now

Hello Andy,

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

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

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

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

Re: [Freeipa-users] SSSD client (amazon linux) + IPA server (Redhat)

[Alexander Bokovoy]

On Mon, 21 Sep 2015, Gustavo Mateus wrote:

Hi Alexander,

Thank you very much for your help.
Would it be possible for you to point me in the right direction on how to
integrate this with sudo rules?

Please don't send emails personally unless asked to do that.

Your problem can be tracked with public mailing list.


my sssd.conf looks like this:

[sssd]
services = nss, pam, ssh, sudo
config_file_version = 2
domains = default
re_expression = (?P.+)

[domain/default]
cache_credentials = True
id_provider = ldap
auth_provider = ldap
ldap_uri = ldap://ipaserver.my.domain.com
ldap_search_base = cn=accounts,dc=my,dc=domain,dc=com
ldap_tls_cacert = /etc/openldap/cacerts/ipa.crt
ldap_user_ssh_public_key = ipaSshPubKey
sudo_provider = ldap
ldap_sudo_search_base = ou=sudoers,dc=my,dc=domain,dc=com
ldap_sudo_full_refresh_interval=86400
ldap_sudo_smart_refresh_interval=3600
debug_level=8

[ssh]

[sudo]
debug_level=8


and nsswitch.conf has this:

sudoers:files sss



My goal is to have freeipa as a replacement for the current openldap and
hope that amazon linux supports it fully in the future. While they don't
support it, I want to use as much as I can of centralized management that
freeipa+sssd provides.

SSSD has own plugin for sudo integration that makes possible to cache
sudo rules via SSSD itself as opposed to use of sudo's LDAP plugin which
tries to talk to LDAP server directly.

You need to understand what features are provided by Amazon Linux's sudo
package. It may well be missing support for sudo plugins. I don't have
access to Amazon Linux source code, thus I cannot check whether their
sudo package supports external plugins.

So even if your sssd version includes sudo plugin, it may probably be
simply unused by your sssd version. Again, I have no idea how Amazon's
Linux AMI is built, thus it may miss this capability.

At this point I'd suggest you to investigate yourself and contact Amazon
support for finding out exactly what is happening there.

--
/ 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] rhel 6.7 upgrade - sssd/sudo

[Andy Thompson]

> > On Mon, Sep 21, 2015 at 07:39:01PM +, Andy Thompson wrote:
> > > > -Original Message-
> > > > From: Jakub Hrozek [mailto:jhro...@redhat.com]
> > > > Sent: Monday, September 21, 2015 3:29 PM
> > > > To: Andy Thompson 
> > > > Cc: freeipa-users@redhat.com; pbrez...@redhat.com
> > > > Subject: Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo
> > > >
> > > > On Mon, Sep 21, 2015 at 02:22:54PM +, Andy Thompson wrote:
> > > > > >
> > > > > > On Thu, Sep 17, 2015 at 11:42:54AM +, Andy Thompson wrote:
> > > > > > > I've narrowed it down a bit doing some testing.  The sudo
> > > > > > > rules work when
> > > > > > I remove the user group restriction from them.  My sudo rules
> > > > > > all have my ad groups in the rule
> > > > > > >
> > > > > > >   Rule name: ad_linux_admins
> > > > > > >   Enabled: TRUE
> > > > > > >   Host category: all
> > > > > > >   Command category: all
> > > > > > >   RunAs User category: all
> > > > > > >   RunAs Group category: all
> > > > > > >   User Groups: ad_linux_admins  <- if I remove this then the
> > > > > > > rule gets
> > > > > > applied
> > > > > >
> > > > > > Nice catch. Is the group visible after you login and run id?
> > > > > >
> > > > > > What is the exact IPA server version?
> > > > >
> > > > > Ok I also figured out if I rename my AD groups to match my IPA
> > > > > groups then
> > > > the sudo rules are applied.
> > > > >
> > > > > I tested a couple things though, if I put a rule in the local
> > > > > sudoers file on a server running sssd 1.11
> > > > >
> > > > > %@   "sudo commands"
> > > > >
> > > > > That rule was not applied.  If I remove the  then
> > > > > the rule got
> > > > applied.
> > > > >
> > > > > On a server running sssd 1.12 that rule works, but does not work
> > > > > if I
> > > > remove the .  And none of the IPA sudo rules work.  So
> > > > something changed with the domain suffix between versions it would
> > > > appear.
> > > > >
> > > > > They key to making the IPA sudo rules work in 1.12 is to remove
> > > > > the
> > > > default_domain_suffix setting in the sssd.conf, but that's not an
> > > > option in my environment.
> > > > >
> > > > > So all the moving parts together, it appears that having AD
> > > > > groups with a different name than the IPA groups in conjunction
> > > > > with the default_domain_suffix setting breaks things right now in
> 1.12.
> > > > > Appears since I renamed the ad group to match then the rule
> > > > > without a domain suffix will get matched now
> > > >
> > > > Hello Andy,
> > > >
> > > > I'm sorry for the constant delays, but I was busy with some
> > > > trust-related fixes lately.
> > > >
> > > > Did you have a chance to confirm that just swapping sssd /on the
> > > > client/ while keeping the same version on the server fixes the
> > > > issue for
> > you?
> > > >
> > > > Pavel (CC), can you help me out here, please? I have the setup
> > > > ready on my machine, so tomorrow we can take a look and experiment
> > > > (I can give you access to my environment via tmate maybe..), but I
> > > > wasn't able to reproduce the issue locally yet.
> > >
> > > It's fine I understand the backlog.
> > >
> > > I was not able to backrev the sssd due to dependency issues.  I
> > > tried
> > downgrading all the dependencies and got in a loop and stopped trying.
> > Are there any tricks you can think of to downgrade the sssd cleanly?
> > >
> > > -andy
> > >
> >
> > What failures are you getting? I normally just download all \*sss\*
> > packages and then downgrade with rpm -U --oldpackage.
> 
> 
> I'm just trying to use yum.  If I yum downgrade sssd I get a ton of deps.  If
> include all the deps it lists
> 
> yum downgrade sssd sssd-proxy sssd-ipa sssd-common-pac sssd-krb5 sssd-
> krb5-common sssd-ldap sssd-ad libipa_hbac libipa_hbac-python python-
> sssdconfig
> 
> I get multilib errors with libsss_idmap.
> 
> Looks like my local repo doesn't have libsss_idmap 1.11 available.  Let me
> look into that and see what repo it sits in and see if I can figure out why 
> it's
> not pulling in.

No it appears to be there 

libsss_idmap-1.9.2-82.el6.i686 : FreeIPA Idmap library
libsss_idmap-1.9.2-82.el6.x86_64 : FreeIPA Idmap library
libsss_idmap-1.9.2-82.4.el6_4.i686 : FreeIPA Idmap library
libsss_idmap-1.9.2-82.4.el6_4.x86_64 : FreeIPA Idmap library
libsss_idmap-1.9.2-82.7.el6_4.i686 : FreeIPA Idmap library
libsss_idmap-1.9.2-82.7.el6_4.x86_64 : FreeIPA Idmap library
libsss_idmap-1.9.2-82.10.el6_4.i686 : FreeIPA Idmap library
libsss_idmap-1.9.2-82.10.el6_4.x86_64 : FreeIPA Idmap library
libsss_idmap-1.11.6-30.el6_6.3.i686 : FreeIPA Idmap library
libsss_idmap-1.11.6-30.el6_6.3.x86_64 : FreeIPA Idmap library
libsss_idmap-1.11.6-30.el6_6.4.i686 : FreeIPA Idmap library
libsss_idmap-1.11.6-30.el6_6.4.x86_64 : FreeIPA Idmap library
libsss_idmap-1.12.4-47.el6.i686 : FreeIPA Idmap library
libsss_idmap-1.12.4-47.el6.x86_64 : FreeIPA Idmap library
libsss_idmap-1.12.4-47.el6.x86_64 : FreeIPA Idmap