[Freeipa-users] Question about ipa user accounts and the compat container

[Robert Johnson]

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.

If you are interesting in seeing this action, you can see the duplicate
entries in the compat tree on the lab system right now.


On Sun, Mar 12, 2017 at 2:58 PM, Alexander Bokovoy <abokovoy at redhat.com>
wrote:

> On su, 12 maalis 2017, Robert Johnson wrote:
>
>> On Fri, Mar 10, 2017 at 1:16 AM, Alexander Bokovoy <abokovoy at redhat.com>
>> wrote:
>>
>> On to, 09 maalis 2017, Robert Johnson wrote:
>>>
>>> On Thu, Mar 9, 2017 at 4:06 PM, Alexander Bokovoy <abokovoy at redhat.com>
>>>> wrote:
>>>>
>>>> On to, 09 maalis 2017, Robert Johnson wrote:
>>>>
>>>>>
>>>>> Hello,
>>>>>
>>>>>>
>>>>>> I am running into an odd issue haven't been able to find any
>>>>>> information
>>>>>> through searching on this issue online.
>>>>>>
>>>>>> Environment: We are currently have a IPA master running
>>>>>> ipa-server-4.4.0-14.el7_3.4.x86_64 on a RHEL 7.3 server.  We have a
>>>>>> mix
>>>>>> of
>>>>>> RHEL 6.8, RHEL 7.x and Solaris 10 clients. We also have a one way
>>>>>> trust
>>>>>> to
>>>>>> a windows domain.  Compatibility mode is enabled.
>>>>>>
>>>>>> The issue I'm seeing is that when I delete an IPA domain user through
>>>>>> the
>>>>>> web gui, the user account doesn't appear to be removed completely from
>>>>>> the
>>>>>> system.  I verified via "ipa user-find" that the user is no longer in
>>>>>> the
>>>>>> system.  I also checked via "ldapsearch" that the user account doesn't
>>>>>> exist in the "accounts" container.  However, when I look in the
>>>>>> "users,
>>>>>> compat" container, that user still exists.
>>>>>>
>>>>>> This is causing problems with my Solaris clients since they are
>>>>>> pointing
>>>>>> to
>>>>>> the compat tree so that we can login with the windows accounts on
>>>>>> those
>>>>>> servers.  The Solaris client is still seeing the account as being
>>>>>> valid
>>>>>> and
>>>>>> is asking the user for a password on login which fails because the
>>>>>> account
>>>>>> doesn't exist in the IPA domain anymore.
>>>>>>
>>>>>> Do I need to remove the account from the ldap compat container
>>>>>> manually
>>>>>> or
>>>>>> is the IPA user delete command (through the gui and/or command line)
>>>>>> suppose to take care of this ?  Or is there is some sort of clean up
>>>>>> process that I have to wait for to occur before this account gets
>>>>>> removed
>>>>>> from that container ?  If so, what is the time frame ?
>>>>>>
>>>>>> Compat tree is automatically generated. It also tracks existing
>>>>>> objects,
>>>>>>
>>>>> so any time the object is removed from the primary tree, it should be
>>>>> cleared from the compat tree as well.
>>>>>
>>>>> If you can reliably demonstrate the problem using
>>>>> http://www.freeipa.org/page/Demo (it has compat tree enabled), then
>>>>> feel
>>>>> free to open a bug.
>>>>>
>>>>> --
>>>>> / Alexander Bokovoy
>>>>>
>>>>>
>>>>> So after doing some more digging using ldapsearch, I discovered some
>>>> "odd"
>>>> entries.  It appears that all my IPA users appear to have duplicate
>>>> entries
>>>> under the compat tree. So on a hunch I deleted another IPA user and one
>>>> of
>>>> the two entries disappeared from the container.  I tried to use
>>>> ldapdelete
>>>> (and ldapmodify) to remove the "ghost" entry using the DN I found from
>>>> the
>>>> search and I get a "object not found" and then it says that it matched
>>>> the
>>>> base tree.  If I dump the whole compat tree out to a file, the ghost
>>>> objects look to be exact duplicates of the original entries (minus the
>>>> guid
>>>> which is different).  I can't seem to find a way to remove them.
>>>>
>>>> Any ideas ?
>>>>
>>>> Demonstrate your problem using the FreeIPA demo instance, please.
>>>
>>> Compat tree is not writable, thus you cannot delete anything from it
>>> directly. You only can delete the original entry to cause removal of a
>>> compat entry.
>>>
>>> Show how it is not removed with step by step ldapsearch/ipa CLI
>>> operations against our demo instance, please.
>>>
>>> --
>>> / Alexander Bokovoy
>>>
>>>
>> Ok, I believe I have been able to reproduce the problem.
>> 1) Before I created the new user, I verified by using the ldapsearch
>> command on the compat tree that the user I was going to create didn't
>> exist:
>> ldapsearch -b "cn=compat,dc=demo1,dc=freeipa,dc=org" -h
>> ipa.demo1.freeipa.org -s sub "(&(objectclass=*)(uid=123456))"
>> Returns nothing
>> ldapsearch -b "cn=accounts,dc=demo1,dc=freeipa,dc=org" -h
>> ipa.demo1.freeipa.org -s sub "(&(objectclass=*)(uid=123456))"
>> Returns nothing
>> Note: I also tried just dumping all the user objects to a file and made
>> sure it wasn't there.
>>
>> 2) Next, I login to the webui and then create the new user.
>> userlogin: 123456
>> First Name: Test
>> Last Name: User
>> and then a password.
>>
>> 3) Next I verified that the account was showing up in the compat tree:
>> ldapsearch -b "cn=compat,dc=demo1,dc=freeipa,dc=org" -h
>> ipa.demo1.freeipa.org -s sub "(&(objectclass=*)(uid=123456))"
>> version: 1
>> dn: uid=123456,cn=users,cn=compat,dc=demo1,dc=freeipa,dc=org
>> objectClass: posixAccount
>> objectClass: ipaOverrideTarget
>> objectClass: top
>> gecos: Test User
>> cn: Test User
>> uidNumber: 1120000053
>> gidNumber: 1120000053
>> loginShell: /bin/sh
>> homeDirectory: /home/123456
>> ipaAnchorUUID::
>> OlNJRDpTLTEtNS0yMS0zNjIwNjU0ODcyLTY4NzE1NzE0Mi00MDUwMjk3OTIzL
>> TEwNTM=
>> uid: 123456
>>
>> 4) I delete the same user account via the webgui (full delete).
>>
>> 5) I then check the compat tree again and here is the result:
>> ldapsearch -b "cn=compat,dc=demo1,dc=freeipa,dc=org" -h
>> ipa.demo1.freeipa.org -s sub "(&(objectclass=*)(uid=123456))"
>> version: 1
>> dn: uid=123456,cn=users,cn=compat,dc=demo1,dc=freeipa,dc=org
>> objectClass: posixAccount
>> objectClass: ipaOverrideTarget
>> objectClass: top
>> gecos: Test User
>> cn: Test User
>> uidNumber: 1120000053
>> gidNumber: 1120000053
>> loginShell: /bin/sh
>> homeDirectory: /home/123456
>> ipaAnchorUUID::
>> OlNJRDpTLTEtNS0yMS0zNjIwNjU0ODcyLTY4NzE1NzE0Mi00MDUwMjk3OTIzL
>> TEwNTM=
>> uid: 123456
>>
>> The user account is still there.
>>
> Thanks, this is helpful.
>
>> Now what is really weird is that if I recreate the user 123456 through the
>> webgui and perform the ldapsearch, I see two entries.  If I delete the
>> user, it removes one of the entries and leaves the shadow one above.  I
>> can
>> tell because the accounts look identical except for the ipaAnchorUUID
>> attribute.
>>
> This is a bug then. Could you please file a ticket?
>
> - This is a problem for our Solaris systems, as the ldap client is pointing
>> to the compat tree so when the accounts are still active in the ipa domain
>> (ie they are in the accounts tree) I am seeing 2 entries when using the
>> getent passwd command.  Needless to say the pam_ldap module doesn't like
>> the two entries.
>>
> No, this is a wrong setup. Either you are using compat tree and have your
> base DN in pam_ldap config set to cn=compat,$SUFFIX, or you are using
> primary tree and then set base dn to cn=accounts,$SUFFIX. You shouldn't
> mix them in your configuration.
>
> Compat tree is just that: a tree that returns data in a format
> compatible with RFC2307 to clients that do not understand RFC2307bis. A
> second use for the compat tree is to provide unified virtual tree for
> clients that do not use SSSD so that both users from IPA and from
> trusted Active Directory forests are accessible by such 'legacy'
> clients. This second use case requires that you are using RFC2307 schema
> in your client setup and that AD users are always fully qualified
> (user at ad.domain).
>
> So if you have configured your client to look at $SUFFIX, it is actually
> expected that the client would see both entries (original one and the
> one from the virtual tree) because that's how they were designed. Thus,
> use a proper, narrow, base DN, like cn=accounts,$SUFFIX for the primary
> IPA tree and cn=compat,$SUFFIX for the compat tree but never $SUFFIX.
>
> SSSD clients handle this automatically. For IPA provider, SSSD
> automatically sets search base to cn=accounts,$SUFFIX and uses
> IPA-specific LDAP extended operation to query IPA servers for
> information about users from Active Directory forests IPA domain trusts.
>
> --
> / Alexander Bokovoy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20170312/b86e3dc4/attachment.htm>