[Freeipa-users] Re: Failed to retrieve entry 32

[Rob Crittenden via FreeIPA-users]

wenxing zheng via FreeIPA-users wrote:
> Dear all,
> 
> I met with an issue when doing the LDAP authentication on the Kylin. My
> FreeIPA works with Ranger very well, but on Kylin, when binding the DN
> with the admin, it failed to connect to the LDAP server:
> 
> [05/Jul/2017:11:16:32 +0800] ipalockout_preop - [file ipa_lockout.c,
> line 756]: Failed to retrieve entry
> "uid=admin,cn=users,cn=accounts,dc=dat...": 32
> [05/Jul/2017:11:16:32 +0800] ipalockout_preop - [file ipa_lockout.c,
> line 756]: Failed to retrieve entry
> "uid=admin,cn=users,cn=accounts,dc=dat...": 32

I don't know what either Kylin or Ranger are. The only advice I can
suggest is to ensure the whole DN is correct (the dc= bits). The plugin
is just trying to fetch the entry that is doing the BIND. My memory is
fuzzy on the ordering of the plugins, it's possible that the bind hasn't
been authenticated yet at this point, I'm not sure.

You should be able to test on the command-line which might make this easier:

$ ldapsearch -D uid=admin,cn=users,cn=accounts,dc=example,dc=com -W -b
uid=admin,cn=users,cn=accounts,dc=example,dc=com

rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Failed to retrieve entry 32

[wenxing zheng via FreeIPA-users]

Thanks to Rob.

We finally got the root cause, it's a bug in the application. Our LDAP URL
or DN is too long which triggered a bug in the JDK Properties. Java
Properties doesn't allow the value to be longer than 47, and if the length
is longer than 47, it will truncate the value and append the "..." at the
end.



On Thu, Jul 6, 2017 at 1:33 AM, Rob Crittenden  wrote:

> wenxing zheng via FreeIPA-users wrote:
> > Dear all,
> >
> > I met with an issue when doing the LDAP authentication on the Kylin. My
> > FreeIPA works with Ranger very well, but on Kylin, when binding the DN
> > with the admin, it failed to connect to the LDAP server:
> >
> > [05/Jul/2017:11:16:32 +0800] ipalockout_preop - [file ipa_lockout.c,
> > line 756]: Failed to retrieve entry
> > "uid=admin,cn=users,cn=accounts,dc=dat...": 32
> > [05/Jul/2017:11:16:32 +0800] ipalockout_preop - [file ipa_lockout.c,
> > line 756]: Failed to retrieve entry
> > "uid=admin,cn=users,cn=accounts,dc=dat...": 32
>
> I don't know what either Kylin or Ranger are. The only advice I can
> suggest is to ensure the whole DN is correct (the dc= bits). The plugin
> is just trying to fetch the entry that is doing the BIND. My memory is
> fuzzy on the ordering of the plugins, it's possible that the bind hasn't
> been authenticated yet at this point, I'm not sure.
>
> You should be able to test on the command-line which might make this
> easier:
>
> $ ldapsearch -D uid=admin,cn=users,cn=accounts,dc=example,dc=com -W -b
> uid=admin,cn=users,cn=accounts,dc=example,dc=com
>
> rob
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Syncronization on servers

[Ataliba Teixeira via FreeIPA-users]

All the problems are solved.

Thanks for all :)


On Tue, Jun 27, 2017 at 1:11 PM Ataliba Teixeira  wrote:

> Hello Rob,
>
> The strange thing i have here is. The server2 has all of my servers listed
> on the web interface but the server1 not have all of this servers.
>
> When i run the command :
>
> # ipa-replica-manage list -v server2.domain
> server1.domain: replica
>   last init status: None
>   last init ended: 1970-01-01 00:00:00+00:00
>   last update status: Error (0) Replica acquired successfully: Incremental
> update succeeded
>   last update ended: 2017-06-27 14:57:34+00:00
>
>
> # ipa-replica-manage list -v server1.domain
> server2.domain: replica
>   last init status: None
>   last init ended: 1970-01-01 00:00:00+00:00
>   last update status: Error (0) Replica acquired successfully: Incremental
> update succeeded
>   last update ended: 2017-06-27 14:57:41+00:00
>
>
> No problems with the sincronization.
>
> My doubt is this. Why i have differences on the two web interfaces.
> Another error i have in the structure is this :
>
>
> # ssh app01
> @@@
> @WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
> @@@
> IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
> Someone could be eavesdropping on you right now (man-in-the-middle attack)!
> It is also possible that a host key has just been changed.
> The fingerprint for the RSA key sent by the remote host is
> f5:21:f0:0c:b7:4b:cf:c4:f2:8f:9c:8a:75:d3:55:5c.
> Please contact your system administrator.
> Add correct host key in /root/.ssh/known_hosts to get rid of this message.
> Offending RSA key in /var/lib/sss/pubconf/known_hosts:4
> RSA host key for app01 has changed and you have requested strict checking.
> Host key verification failed.
>
> And this server is one of the servers listed on server2 and not on the
> server1 .
>
> Thanks for your help,
>
>
>
> On Tue, Jun 27, 2017 at 11:47 AM Rob Crittenden 
> wrote:
>
>> Ataliba Teixeira via FreeIPA-users wrote:
>> > Hello,
>> >
>> > reading some docs about the sync of my two servers :
>> >
>> > # ipa-replica-manage list
>> > server1.domain: master
>> > server2.domain: master
>> >
>> >
>> > # ipa-replica-manage list-ruv
>> > Directory Manager password:
>> >
>> > Replica Update Vectors:
>> > server2.domain:389: 7
>> > server1.domain:389: 4
>> > Certificate Server Replica Update Vectors:
>> > No CS-RUVs found.
>> >
>> >
>> > My doubt is . To solve this i only need to run the command :
>> >
>> > ipa-replica-manage force-sync --from srv2.domain
>>
>> I'm not sure what problem you are trying to solve. The above doesn't
>> show any issues.
>>
>> To see replication status you need to run ipa-replica-manage list twice
>> like:
>>
>> ipa-replica-manage list -v server1.domain
>> ipa-replica-manage list -v server2.domain
>>
>> This will show the agreement status from both sides.
>>
>> rob
>>
> --
>
> Ataliba Teixeira via Inbox by Gmail
>
-- 

Ataliba Teixeira via Inbox by Gmail
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: HBAC rules / ssh keys for AD users not working right away

[Lachlan Musicman via FreeIPA-users]

Bart,

Which versions of SSSD and FreeIPA are you using?

cheers
L.

--
"Mission Statement: To provide hope and inspiration for collective action,
to build collective power, to achieve collective transformation, rooted in
grief and rage but pointed towards vision and dreams."

 - Patrisse Cullors, *Black Lives Matter founder*

On 6 July 2017 at 00:22, bogusmaster--- via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

> Hi all,
>
> I have set up trust between FreeIPA and AD. Users from AD domain can
> successfully log into the linux boxes when I have allow_all rule enabled.
> However, when I try to achieve something more fancy, like assigning set of
> users to a custom group (firstly external, then the posix one) or make it
> possible for AD users to use ssh public key authentication via Default
> Trust View user settings override, FreeIPA behaves in slightly
> nondeterministic way. It manifests itself in a couple of ways:
> - users that I uploaded SSH keys for can't use them right away. Sometimes
> it is a matter of minutes, sometimes it is a matter of hours for the ssh
> public keys to work. I observed that when I add a couple of keys, then
> whenever one ssh public key starts working for one user, it works for all
> of them.
> - the same as above applies to AD users that are added to a group which
> later on is used in HBAC rule definition. When I add a user to this group,
> he/she can't log in straight away but it takes some time to propagate.
> - and last but not least: when I delete a user who can successfully log
> into a Linux box from a group which is used in HBAC rule definition, he/she
> can still log in to that box. To make things more awkward, user can access
> one client machine as if they wasn't deleted from the group whereas they
> can't access other client machine and receives "Connection closed by
> UNKNOWN" response upon ssh connection establishment (which is desired in
> both Linux machines).
>
> I tried to clear sssd cache by issuing sss_cache -E and restarted sssd
> daemon  on Linux machine which is affected by that behaviour, but to no
> avail.
>
> Can someone please point me to what I can do to troubleshoot this further
> and make changes applied to IPA server be visible right away?
>
> Many thanks,
> Bart
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org