Re: [Freeipa-users] SSSD bug found? FreeIPA vs SSSD

[Lachlan Musicman]

I am still having problems with FreeIPA/HBAC, SSSD and logging into hosts.
Could this be the reason that SSSD isn't picking up the full list of groups
a user belongs to?

In particular, ipa hbac test says true. "id domain\\username" or "id
username@domain" returns the correct groups. But the
sssd_domain.com.log- shows hbac_eval_user_element returning a list of
groups that doesn't include the IPA groups in the HBAC rule? (it does
return the AD group that is the external group that the IPA group would
register as being HBAC true, but not the matching IPA group)

cheers
L.


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

- Grace Hopper

On 9 March 2017 at 20:39, Jakub Hrozek  wrote:

> On Thu, Mar 09, 2017 at 11:32:35AM +0200, Alexander Bokovoy wrote:
> > On to, 09 maalis 2017, Jakub Hrozek wrote:
> > > On Thu, Mar 09, 2017 at 01:37:46PM +1100, Lachlan Musicman wrote:
> > > > Hola,
> > > >
> > > > On CentOS 7.3, using FreeIPA VERSION: 4.4.0, API_VERSION: 2.213 and
> sssd
> > > > (via COPR) 1.15.1, which has a one way trust to an AD domain.
> unix.name.org
> > > > -> name.org
> > > >
> > > > I've seen some interesting behaviour.
> > > >
> > > > Being part of a large organisation with a smaller nix environment
> and a
> > > > larger Windows environment we see all the best of odd AD management
> > > > behaviour (eg spaces in usernames...).
> > > >
> > > > Turns out some of the groups in AD have an @ symbol in them.
> > > >
> > > > The behavioural difference we see is: given userA in group "name @ of
> > > > group" that on the FreeIPA server:
> > > >
> > > > [r...@vmpr-freeipa.unix.name.org ~]# id us...@name.org
> > > >
> > > > works as expected.
> > > >
> > > > But on a client
> > > >
> > > > [r...@vmpr-linuxclient1.unix.name.org ~]# id us...@name.org
> > > >
> > > > returns nothing.
> > >
> > > Yes, it is a know issue:
> > >https://pagure.io/SSSD/sssd/issue/3219
> > >
> > > There were some users who reported this works better with a modified
> > > re_expression:
> > >re_expression = ((?P.+)@(?P[^@]+$))
> > > but I agree we should fix this by default. However, the fix must be
> done
> > > at both the SSSD level and the IPA extdom plugin, which also searches
> > > for the @-sign in the user and group names.
> > Luckily, a change for extdom plugin seem to be straightforward -- search
> > for the *last* occurence of the domain separator, not the first one. We
> > had a similar issue with nfs idmapd code too.
>
> Yes, the most tricky part would be testing, to make sure the new regular
> expression doesn't break anything. I used the one I showed to unblock
> some RHEL customers that were complaining and were a bit stuck, but I
> didn't have enough time to run all our available tests with it, that's
> why we didn't switch by default..
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] install freeipa amazon Linux

[Lukas Slebodnik]

On (13/03/17 00:16), barry...@gmail.com wrote:
>Hi:
>
>anyone has exp install freeipa in amazon linx base on fredora?
>
>I tried install repo myself but it fail only say no such freeipa
>
>which repo ishould use ...I already tried many difference source still fail.
>
>it seem it has its own amaz limux repo.
>
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

I would recommend either to use compat tree + nslcd
or use CentOS, RHEL, other distribution which has ipa-client

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] Add host to hostgroup in ipa-client-add

[Orion Poplawski]

On 03/10/2017 10:52 PM, Alexander Bokovoy wrote:
> On pe, 10 maalis 2017, Orion Poplawski wrote:
>> I'm using ipa-client-add with --unattended and a OTP to enroll machines at
>> install time.  I'd like to be able to add them to a particular hostgroup at
>> the same time to avoid having to do that manually later.  Does this seem like
>> a reasonable RFE?  Or is there some other way to handle this?
> Use automember rules:
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/automember.html

Interesting but I don't think this will help me.

After thinking about this a bit more, since I need to add the host anyway to
set the OTP, I just added setting group membership to that script as well.

Thanks for the info though.


-- 
Orion Poplawski
Technical Manager  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com

-- 
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] Read-only replicas?

[Stephen]

Is there read-only replica support in freeipa? The use case is a dmz.

Thanks...

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

Re: [Freeipa-users] ldap tree: etc-location & ca-cas

[Martin Basti]

On 11.03.2017 14:11, lejeczek wrote:
> hi everyone
>
> my domain seems ok but I've decided to watch it closely on more
> regular basis and am in a process of learning the tree.
> I found a few +nsuniqueid and I wonder: is there a relation (surely
> is, but how critical) between etc-location & ca-ca?
>
> Both, location and ca have the same
> +nsuniqueid=647ed0ab-b70911e6-b84df1c7-2176fa48.
> My question would be (if I cannot do that with IPA, which I probably
> cannot): do I clean manually both location & ca in one go?
> Or there is a sequence to it?
> And more importantly: what should also check in the tree in relation
> to these two DNs?
>
> many thank,
> L
>
>

Hi,

you have a replication conflict
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html


signature.asc
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] Question about ipa user accounts and the compat container

[Alexander Bokovoy]

On su, 12 maalis 2017, Robert Johnson wrote:

On Sun, Mar 12, 2017 at 4:45 PM, Alexander Bokovoy 
wrote:


On su, 12 maalis 2017, Robert Johnson wrote:


Sorry I should have given some more information. We are trying to allow
the
user's from the trusted windows domain to login to the Solaris client and
the only way I have found to have this work is by using the
cn=compat,$SUFFIX for the passwd as this will force the ldap client to to
use the slapi plugin on the ipa server.  This required using ldapclient
manual on the solaris system instead of the default profile (which uses
cn=accounts for passwd).

ex:
ldapclient list for default profile shows: (supports IPA users just fine)
NS_LDAP_SEARCH_BASEDN= $SUFFIX
NS_LDAP_SERVICE_SEARCH_DESC= passwd:cn=users,cn=accounts,$SUFFIX
NS_LDAP_SERVICE_SEARCH_DESC= group:cn=groups,cn=compat,$SUFFIX

ldaplist list for my manual profile shows: (supports windows users just
fine)
NS_LDAP_SEARCH_BASEDN= $SUFFIX
NS_LDAP_SERVICE_SEARCH_DESC= passwd:cn=users,cn=compat,$SUFFIX
NS_LDAP_SERVICE_SEARCH_DESC= group:cn=groups,cn=compat,$SUFFIX

What we were trying to do is also allow IPA created user's to login to the
Solaris client in addition to the windows user's.  This is where I started
to run into problems with the pam_ldap module as it was detecting the
duplicate entries from the "bug" above.


Thanks for the details.

So, why don't you set NS_LDAP_SEARCH_BASEDN = cn=compat,$SUFFIX?



I tried that and I still see the same issue. I believe the problem is that
the duplicate entries are located in the cn=users,cn=compat tree.  The ldap
client on the Solaris system isn't seeing any of the user's in the
cn=accounts tree.  I think this is all related to the bug above because
when I preform the ldapsearch on the compat tree, I am seeing double
entries for my ipa' users.

I'm lost here: if you set NS_LDAP_SEARCH_BASEDN and other bases to
cn=compat,$SUFFIX only, your Solaris client sees duplicate entries in
cn=compat,$SUFFIX?

Sorry, it would really help if you be more detailed in your
explanations. If you are setting up Solaris LDAP client to always look
into cn=compat,$SUFFIX, then how cn=accounts,$SUFFIX is being searched?

Can you show 389-ds access log entries that demonstrate these searches?

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