[Freeipa-users] kinit not working for some accounts

[Tiemen Ruiten via FreeIPA-users]

Hello,

I've just noticed that kinit is not working for several but not all
accounts in our FreeIPA domain (4.4.0-14.el7.centos.7). I get the following
error:

on the client:

[root@caesium tiemen]# KRB5_TRACE=/dev/stdout kinit *dba*
[7827] 1498729905.996951: Resolving unique ccache of type KEYRING
[7827] 1498729905.997071: Getting initial credentials for d...@i.rdmedia.com
[7827] 1498729905.997811: Sending request (167 bytes) to I.RDMEDIA.COM
[7827] 1498729905.998340: Initiating TCP connection to stream
10.100.110.36:88
[7827] 1498729906.2356: Sending TCP request to stream 10.100.110.36:88
[7827] 1498729906.9304: Received answer (204 bytes) from stream
10.100.110.36:88
[7827] 1498729906.9334: Terminating TCP connection to stream
10.100.110.36:88
[7827] 1498729906.9621: Response was from master KDC
[7827] 1498729906.9683: Received error from KDC: -1765328359/Additional
pre-authentication required
*[7827] 1498729906.9780: Processing preauth types: 136, 133*
*[7827] 1498729906.9795: Received cookie: MIT*
*kinit: Generic preauthentication failure while getting initial credentials*

whereas

[root@caesium tiemen]# KRB5_TRACE=/dev/stdout kinit *admin*
[7869] 1498730079.918191: Resolving unique ccache of type KEYRING
[7869] 1498730079.918290: Getting initial credentials for
ad...@i.rdmedia.com
[7869] 1498730079.918896: Sending request (169 bytes) to I.RDMEDIA.COM
[7869] 1498730079.919370: Initiating TCP connection to stream
10.100.110.36:88
[7869] 1498730079.922958: Sending TCP request to stream 10.100.110.36:88
[7869] 1498730079.930832: Received answer (258 bytes) from stream
10.100.110.36:88
[7869] 1498730079.930857: Terminating TCP connection to stream
10.100.110.36:88
[7869] 1498730079.930977: Response was from master KDC
[7869] 1498730079.931039: Received error from KDC: -1765328359/Additional
pre-authentication required
*[7869] 1498730079.931106: Processing preauth types: 136, 19, 2, 133*
*[7869] 1498730079.931129: Selected etype info: etype aes256-cts, salt
"REDACTED", params ""*
*[7869] 1498730079.931139: Received cookie: MIT*

*Password for t...@i.rdmedia.com :*

What could explain this difference? Where can I look to debug this?


-- 
Tiemen Ruiten
Systems Engineer
R Media
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: kinit not working for some accounts

[Tiemen Ruiten via FreeIPA-users]

Nevermind, the users didn't have a password set.

On 29 June 2017 at 12:02, Tiemen Ruiten  wrote:

> Hello,
>
> I've just noticed that kinit is not working for several but not all
> accounts in our FreeIPA domain (4.4.0-14.el7.centos.7). I get the following
> error:
>
> on the client:
>
> [root@caesium tiemen]# KRB5_TRACE=/dev/stdout kinit *dba*
> [7827] 1498729905.996951: Resolving unique ccache of type KEYRING
> [7827] 1498729905.997071: Getting initial credentials for
> d...@i.rdmedia.com
> [7827] 1498729905.997811: Sending request (167 bytes) to I.RDMEDIA.COM
> [7827] 1498729905.998340: Initiating TCP connection to stream
> 10.100.110.36:88
> [7827] 1498729906.2356: Sending TCP request to stream 10.100.110.36:88
> [7827] 1498729906.9304: Received answer (204 bytes) from stream
> 10.100.110.36:88
> [7827] 1498729906.9334: Terminating TCP connection to stream
> 10.100.110.36:88
> [7827] 1498729906.9621: Response was from master KDC
> [7827] 1498729906.9683: Received error from KDC: -1765328359/Additional
> pre-authentication required
> *[7827] 1498729906.9780: Processing preauth types: 136, 133*
> *[7827] 1498729906.9795: Received cookie: MIT*
> *kinit: Generic preauthentication failure while getting initial
> credentials*
>
> whereas
>
> [root@caesium tiemen]# KRB5_TRACE=/dev/stdout kinit *admin*
> [7869] 1498730079.918191: Resolving unique ccache of type KEYRING
> [7869] 1498730079.918290: Getting initial credentials for
> ad...@i.rdmedia.com
> [7869] 1498730079.918896: Sending request (169 bytes) to I.RDMEDIA.COM
> [7869] 1498730079.919370: Initiating TCP connection to stream
> 10.100.110.36:88
> [7869] 1498730079.922958: Sending TCP request to stream 10.100.110.36:88
> [7869] 1498730079.930832: Received answer (258 bytes) from stream
> 10.100.110.36:88
> [7869] 1498730079.930857: Terminating TCP connection to stream
> 10.100.110.36:88
> [7869] 1498730079.930977: Response was from master KDC
> [7869] 1498730079.931039: Received error from KDC: -1765328359/Additional
> pre-authentication required
> *[7869] 1498730079.931106: Processing preauth types: 136, 19, 2, 133*
> *[7869] 1498730079.931129: Selected etype info: etype aes256-cts, salt
> "REDACTED", params ""*
> *[7869] 1498730079.931139: Received cookie: MIT*
>
> *Password for t...@i.rdmedia.com :*
>
> What could explain this difference? Where can I look to debug this?
>
>
> --
> Tiemen Ruiten
> Systems Engineer
> R Media
>



-- 
Tiemen Ruiten
Systems Engineer
R Media
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: password reset privileges

[Tiemen Ruiten via FreeIPA-users]

Hello,

Sorry for the late reply. This is the latest FreeIPA version in CentOS 7.3
(4.4.0-14).

Indeed the helpdesk role should be sufficient. I tried with the User
Administrator role as well, but that made no difference. Since it's working
for you, it's likely a config error, but I have no idea where to look at
this point. Do you have any pointers?

On 4 August 2017 at 19:19, Rob Crittenden <rcrit...@redhat.com> wrote:

> Tiemen Ruiten via FreeIPA-users wrote:
> > As I mentioned in my first mail, that doesn't work. For testing, I
> > created a new role that contains the following privileges:
> >
> > Group Administrators
> > Modify Group membership
> > Modify Users and Reset passwords
> > User Administrators
> >
> > Unfortunately, I get the same error.
>
> What version of IPA is this? The helpdesk role should be sufficient (and
> works for me).
>
> rob
>
> >
> > On 4 August 2017 at 17:40, Bob Rentschler <bob.rentsch...@gmail.com
> > <mailto:bob.rentsch...@gmail.com>> wrote:
> >
> > Assigning roles to your userwill fix that issue. The existing "User
> > Administrator" role may fit your needs, but I am unsure how
> restrictive
> > you want to be with permissions.
> >
> >
> > If you want to be more restrictive a custom role with "System:
> > Change User password" permissions would seem to be the right way.
> >
> > Make a privilege that contains only that permission (and and other
> > missing permissions down the road) add it to a new role and then
> > assign that role to your user.
> >
> >
> > Bob
> >
> > On Fri, Aug 4, 2017 at 10:12 AM, Tiemen Ruiten via FreeIPA-users
> > <freeipa-users@lists.fedorahosted.org
> > <mailto:freeipa-users@lists.fedorahosted.org>> wrote:
> >
> > Hello,
> >
> > I setup an LDAP User Federation in Keycloak to our FreeIPA
> > domain. Unfortunately, the password reset functionality appears
> > to only work when the user Keycloak binds as is in the admins
> > group. I tried both the User Administrator and helpdesk roles,
> > but always got this error:
> >
> > Caused by: javax.naming.NoPermissionException: [LDAP: error code
> > 50 - Insufficient 'write' privilege to the 'userPassword'
> > attribute of entry
> > 'uid=x,cn=users,cn=accounts,dc=example,dc=com'
> >
> > Is there a way to allow password resets without adding the
> > keycloak bind user to the admins group?
> >
> >
> > --
> > Tiemen Ruiten
> > Systems Engineer
> > R Media
> >
> > ___
> > FreeIPA-users mailing list --
> > freeipa-users@lists.fedorahosted.org
> > <mailto:freeipa-users@lists.fedorahosted.org>
> > To unsubscribe send an email to
> > freeipa-users-le...@lists.fedorahosted.org
> > <mailto:freeipa-users-le...@lists.fedorahosted.org>
> >
> >
> >
> >
> >
> > --
> > Tiemen Ruiten
> > Systems Engineer
> > R Media
> >
> >
> > ___
> > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> > To unsubscribe send an email to freeipa-users-leave@lists.
> fedorahosted.org
> >
>
>


-- 
Tiemen Ruiten
Systems Engineer
R Media
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] password reset privileges

[Tiemen Ruiten via FreeIPA-users]

Hello,

I setup an LDAP User Federation in Keycloak to our FreeIPA domain.
Unfortunately, the password reset functionality appears to only work when
the user Keycloak binds as is in the admins group. I tried both the User
Administrator and helpdesk roles, but always got this error:

Caused by: javax.naming.NoPermissionException: [LDAP: error code 50 -
Insufficient 'write' privilege to the 'userPassword' attribute of entry
'uid=x,cn=users,cn=accounts,dc=example,dc=com'

Is there a way to allow password resets without adding the keycloak bind
user to the admins group?


-- 
Tiemen Ruiten
Systems Engineer
R Media
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: password reset privileges

[Tiemen Ruiten via FreeIPA-users]

As I mentioned in my first mail, that doesn't work. For testing, I created
a new role that contains the following privileges:

Group Administrators
Modify Group membership
Modify Users and Reset passwords
User Administrators

Unfortunately, I get the same error.

On 4 August 2017 at 17:40, Bob Rentschler <bob.rentsch...@gmail.com> wrote:

> Assigning roles to your userwill fix that issue. The existing "User
> Administrator" role may fit your needs, but I am unsure how restrictive
> you want to be with permissions.
>
>
> If you want to be more restrictive a custom role with "System: Change User
> password" permissions would seem to be the right way.
>
> Make a privilege that contains only that permission (and and other missing
> permissions down the road) add it to a new role and then
> assign that role to your user.
>
>
> Bob
>
> On Fri, Aug 4, 2017 at 10:12 AM, Tiemen Ruiten via FreeIPA-users <
> freeipa-users@lists.fedorahosted.org> wrote:
>
>> Hello,
>>
>> I setup an LDAP User Federation in Keycloak to our FreeIPA domain.
>> Unfortunately, the password reset functionality appears to only work when
>> the user Keycloak binds as is in the admins group. I tried both the User
>> Administrator and helpdesk roles, but always got this error:
>>
>> Caused by: javax.naming.NoPermissionException: [LDAP: error code 50 -
>> Insufficient 'write' privilege to the 'userPassword' attribute of entry
>> 'uid=x,cn=users,cn=accounts,dc=example,dc=com'
>>
>> Is there a way to allow password resets without adding the keycloak bind
>> user to the admins group?
>>
>>
>> --
>> Tiemen Ruiten
>> Systems Engineer
>> R Media
>>
>> ___
>> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>> To unsubscribe send an email to freeipa-users-le...@lists.fedo
>> rahosted.org
>>
>>
>


-- 
Tiemen Ruiten
Systems Engineer
R Media
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: GSSAPI login from trusted AD domain to FreeIPA clients not working

[Tiemen Ruiten via FreeIPA-users]

I tried the GPO and that actually worked, thanks Robert. I had to specify
all the subdomains we use as well in the value field (we have IPA-clients
in several subdomains of i.rdmedia.com). It appears my issue is solved.

Looking forward to hear what the Microsoft guys say.

On 21 June 2017 at 00:41, Alexander Bokovoy <aboko...@redhat.com> wrote:

> On ti, 20 kesä 2017, Robert Johnson wrote:
>
>> I ran into this exact same problem with my IPA domain in a one way
>> external
>> trust to our Windows 2012 R2 AD forest.  It appears that Microsoft may
>> have
>> removed the routing suffix option from the Windows 2012 R2 native forest
>> trust gui.  My solution was to follow the instructions in the "Define host
>> name-to-Kerberos realm mappings" section of this document from Microsoft:
>> https://support.microsoft.com/en-us/help/947706/windows-serv
>> er-2008-group-policy-settings-for-interoperability-with-non-
>> microsoft-kerberos-realms
>>
> This document is not about a type of trust FreeIPA is using in the case
> of external trust to AD (neither in a normal cross-forest trust).
>
> .
>>
>> Assuming the IPA realm name is the same as the domain name you would use:
>> Value Name: I.RDMEDIA.COM
>> Value: .i.rdmedia.com  (Notice the period at the beginning of the
>> domain name)
>>
>> I applied the GPO to all of my workstations (not the servers) but I don't
>> see any harm across all the windows systems.
>>
> It looks like the GPO change is more of a Kerberos settings modification
> on AD side that basically is equivalent of krb5.conf's [domain_realm]
> section and is not really related to the technology of the trust.
>
> BTW, I reproduced the original issue in a lab at the interop here at
> Microsoft HQ and I'm going to talk to Microsoft guys to find out what is
> happening there in reality.
>
>
>
>> Rob Johnson
>>
>> On Tue, Jun 20, 2017 at 3:04 PM, Alexander Bokovoy via FreeIPA-users <
>> freeipa-users@lists.fedorahosted.org> wrote:
>>
>> On ti, 20 kesä 2017, Tiemen Ruiten via FreeIPA-users wrote:
>>>
>>> Please see the attached screenshot for the Trust settings, and thank you
>>>> for your time.
>>>>
>>>> Thanks. I'm not sure why is that happening even for the immediate forest
>>> root domain that i.rdmedia.com is. I'll check with Microsoft doc help
>>> team while here at the Redmond Interop 2017.
>>>
>>>
>>> --
>>> / Alexander Bokovoy
>>> ___
>>> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>>> To unsubscribe send an email to freeipa-users-le...@lists.fedo
>>> rahosted.org
>>>
>>>
> --
> / Alexander Bokovoy
>



-- 
Tiemen Ruiten
Systems Engineer
R Media
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] GSSAPI login from trusted AD domain to FreeIPA clients not working

[Tiemen Ruiten via FreeIPA-users]

Hello,

I have a FreeIPA domain, i.rdmedia.com, (CentOS 7.3, fully up-to-date: rpm
versions are 4.4.0-14.el7.centos.7) with a two-way, non-transitive,
external trust to an Active Directory domain in another forest,
clients.rdmedia.com, (Windows Server 2012R2). I've setup the trust using
the Administrator credentials.

As one of the final steps, I would like to get passwordless SSH-access
using GSSAPI to work, but unfortunately I get the following error in the
Putty log when connecting from an AD domain-joined client:

Event Log: GSSAPI authentication initialisation failed
Event Log: The target was not recognized

Is it possible to configure GSSAPI authentication for a cross-forest trust
or should I setup the trust as a 'Trusted Forest' ie. not external?

-- 
Tiemen Ruiten
Systems Engineer
R Media
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: GSSAPI login from trusted AD domain to FreeIPA clients not working

[Tiemen Ruiten via FreeIPA-users]

On 20 June 2017 at 18:07, Alexander Bokovoy <aboko...@redhat.com> wrote:

> On ti, 20 kesä 2017, Tiemen Ruiten via FreeIPA-users wrote:
>
>> Hello,
>>
>> I have a FreeIPA domain, i.rdmedia.com, (CentOS 7.3, fully up-to-date:
>> rpm
>> versions are 4.4.0-14.el7.centos.7) with a two-way, non-transitive,
>> external trust to an Active Directory domain in another forest,
>> clients.rdmedia.com, (Windows Server 2012R2). I've setup the trust using
>> the Administrator credentials.
>>
>> As one of the final steps, I would like to get passwordless SSH-access
>> using GSSAPI to work, but unfortunately I get the following error in the
>> Putty log when connecting from an AD domain-joined client:
>>
>> Event Log: GSSAPI authentication initialisation failed
>> Event Log: The target was not recognized
>>
> "Target was not recognized" means your AD DC does not know that
> requests for services in .i.rdmedia.com domain must be routed to FreeIPA
> DC.
> What does
>
>  netdom trust clients.rdmedia.com /namesuffixes:i.rdmedia.com
>
> say on clients.rdmedia.com's DC?


It says: The parameter is incorrect.

Actually, I don't see the Name Suffix Routing tab in the incoming/outgoing
trust properties either, only the General and Authentication tabs.


>
> --
> / Alexander Bokovoy
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: GSSAPI login from trusted AD domain to FreeIPA clients not working

[Tiemen Ruiten via FreeIPA-users]

Please see the attached screenshot for the Trust settings, and thank you
for your time.

On 20 June 2017 at 19:36, Tiemen Ruiten <t.rui...@rdmedia.com> wrote:

> On 20 June 2017 at 18:07, Alexander Bokovoy <aboko...@redhat.com> wrote:
>
>> On ti, 20 kesä 2017, Tiemen Ruiten via FreeIPA-users wrote:
>>
>>> Hello,
>>>
>>> I have a FreeIPA domain, i.rdmedia.com, (CentOS 7.3, fully up-to-date:
>>> rpm
>>> versions are 4.4.0-14.el7.centos.7) with a two-way, non-transitive,
>>> external trust to an Active Directory domain in another forest,
>>> clients.rdmedia.com, (Windows Server 2012R2). I've setup the trust using
>>> the Administrator credentials.
>>>
>>> As one of the final steps, I would like to get passwordless SSH-access
>>> using GSSAPI to work, but unfortunately I get the following error in the
>>> Putty log when connecting from an AD domain-joined client:
>>>
>>> Event Log: GSSAPI authentication initialisation failed
>>> Event Log: The target was not recognized
>>>
>> "Target was not recognized" means your AD DC does not know that
>> requests for services in .i.rdmedia.com domain must be routed to FreeIPA
>> DC.
>> What does
>>
>>  netdom trust clients.rdmedia.com /namesuffixes:i.rdmedia.com
>>
>> say on clients.rdmedia.com's DC?
>
>
> It says: The parameter is incorrect.
>
> Actually, I don't see the Name Suffix Routing tab in the incoming/outgoing
> trust properties either, only the General and Authentication tabs.
>
>
>>
>> --
>> / Alexander Bokovoy
>>
>
>


-- 
Tiemen Ruiten
Systems Engineer
R Media
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: ipa-server-install failing at wait_for_open_ports

[Tiemen Ruiten via FreeIPA-users]

Besides checking your hosts file, also double-check that localhost actually
has an ipv6 address.

On 22 September 2017 at 07:43, Maciej Drobniuch via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

> Hey Eric,
>
> To me looks like either the /etc/hosts file is wrongly configured/dns
> server is not set to ipa or ipa ports are not open.
>
> M.
>
> On Wed, Sep 20, 2017 at 5:30 PM, Eric Scholwin via FreeIPA-users <
> freeipa-users@lists.fedorahosted.org> wrote:
>
>> Foolishly, I blew up my entire 4.4 on Centos 7.4 environment and I'm
>> trying to get 4.5 working on 7.4. I've been hitting the same exact problem
>> while trying to install freeipa 4.5 on centos 7.4 from scratch and that's
>> at step 6/45 "starting directory server". The following message is what I
>> get hung up on during the installation and I'm at a complete loss as to
>> what's going on.
>>
>> DEBUG wait_for_open_ports: localhost [389] timeout 300
>>
>> I, like many others, had ipv6 disabled, but I've re-enabled it, and I'm
>> still running into issues.
>>
>> This is what my ipaserver-install.log looks like, it fails at this
>> samespot every single time:
>>
>> 2017-09-20T15:14:48Z DEBUG wait_for_open_ports: localhost [389] timeout
>> 300
>> 2017-09-20T15:19:49Z DEBUG Traceback (most recent call last):
>>   File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
>> line 504, in start_creation
>> run_step(full_msg, method)
>>   File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
>> line 494, in run_step
>> method()
>>   File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py",
>> line 651, in __start_instance
>> self.start(self.serverid)
>>   File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py",
>> line 627, in start
>> super(DsInstance, self).start(*args, **kwargs)
>>   File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
>> line 401, in start
>> self.service.start(instance_name, capture_output=capture_output,
>> wait=wait)
>>   File "/usr/lib/python2.7/site-packages/ipaplatform/redhat/services.py",
>> line 157, in start
>> instance_name, capture_output=capture_output, wait=wait)
>>   File "/usr/lib/python2.7/site-packages/ipaplatform/base/services.py",
>> line 300, in start
>> self.wait_for_open_ports(self.service_instance(instance_name))
>>   File "/usr/lib/python2.7/site-packages/ipaplatform/base/services.py",
>> line 270, in wait_for_open_ports
>> self.api.env.startup_timeout)
>>   File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line
>> 1227, in wait_for_open_ports
>> raise socket.timeout("Timeout exceeded")
>> timeout: Timeout exceeded
>>
>> 2017-09-20T15:19:49Z DEBUG   [error] timeout: Timeout exceeded
>> 2017-09-20T15:19:49Z DEBUG   File 
>> "/usr/lib/python2.7/site-packages/ipapython/admintool.py",
>> line 172, in execute
>> return_value = self.run()
>>   File "/usr/lib/python2.7/site-packages/ipapython/install/cli.py", line
>> 333, in run
>> cfgr.run()
>>   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
>> line 368, in run
>> self.execute()
>>   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
>> line 392, in execute
>> for _nothing in self._executor():
>>   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
>> line 434, in __runner
>> exc_handler(exc_info)
>>   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
>> line 463, in _handle_execute_exception
>> self._handle_exception(exc_info)
>>   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
>> line 453, in _handle_exception
>> six.reraise(*exc_info)
>>   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
>> line 424, in __runner
>> step()
>>   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
>> line 421, in 
>> step = lambda: next(self.__gen)
>>   File "/usr/lib/python2.7/site-packages/ipapython/install/util.py",
>> line 81, in run_generator_with_yield_from
>> six.reraise(*exc_info)
>>   File "/usr/lib/python2.7/site-packages/ipapython/install/util.py",
>> line 59, in run_generator_with_yield_from
>> value = gen.send(prev_value)
>>   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
>> line 658, in _configure
>> next(executor)
>>   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
>> line 434, in __runner
>> exc_handler(exc_info)
>>   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
>> line 463, in _handle_execute_exception
>> self._handle_exception(exc_info)
>>   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
>> line 521, in _handle_exception
>> self.__parent._handle_exception(exc_info)
>>   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
>> line 453, in _handle_exception
>> six.reraise(*exc_info)
>>   File 

[Freeipa-users] SERVFAIL for one hostname

[Tiemen Ruiten via FreeIPA-users]

Hello,

Since a few days ago, we're having issues with resolution of this hostname:

download.wisselkoersenvoorjeadministratie.nl

Our FreeIPA DNS servers return SERVFAIL for that particular hostname.
What's funny, after I do a (successful) lookup directly at one of the
configured forwarders, 1.1.1.1, resolution works, until the TTL expires.
Other hostnames work fine. How can I troubleshoot this?

FreeIPA versions:
ipa-server-4.6.5-11.el7.centos.4.x86_64
ipa-server-dns-4.6.5-11.el7.centos.4.noarch

[t...@i.rdmedia.com@zinc ~]$ dig download.wisselkoersenvoorjeadministratie.nl

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>>
download.wisselkoersenvoorjeadministratie.nl
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 48732
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;download.wisselkoersenvoorjeadministratie.nl. IN A

;; Query time: 40 msec
;; SERVER: 10.100.110.36#53(10.100.110.36)
;; WHEN: Tue Apr 21 11:58:51 CEST 2020
;; MSG SIZE  rcvd: 73

[t...@i.rdmedia.com@zinc ~]$ dig download.wisselkoersenvoorjeadministratie.nl
@1.1.1.1

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>>
download.wisselkoersenvoorjeadministratie.nl @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58424
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;download.wisselkoersenvoorjeadministratie.nl. IN A

;; ANSWER SECTION:
download.wisselkoersenvoorjeadministratie.nl. 3600 IN A 185.87.187.229

;; Query time: 43 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Tue Apr 21 11:58:59 CEST 2020
;; MSG SIZE  rcvd: 133

[t...@i.rdmedia.com@zinc ~]$ dig download.wisselkoersenvoorjeadministratie.nl

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>>
download.wisselkoersenvoorjeadministratie.nl
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57208
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;download.wisselkoersenvoorjeadministratie.nl. IN A

;; ANSWER SECTION:
download.wisselkoersenvoorjeadministratie.nl. 3600 IN A 185.87.187.229

;; Query time: 24 msec
;; SERVER: 10.100.110.36#53(10.100.110.36)
;; WHEN: Tue Apr 21 11:59:01 CEST 2020
;; MSG SIZE  rcvd: 89


-- 
Tiemen Ruiten
Infrastructure Engineer
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: SERVFAIL for one hostname

[Tiemen Ruiten via FreeIPA-users]

On Tue, Apr 21, 2020 at 1:10 PM Tiemen Ruiten  wrote:

> Hello,
>
> On Tue, Apr 21, 2020 at 12:46 PM François Cami  wrote:
>
>> Hi,
>>
>> On Tue, Apr 21, 2020 at 12:19 PM Tiemen Ruiten via FreeIPA-users
>>  wrote:
>> >
>> > Hello,
>> >
>> > Since a few days ago, we're having issues with resolution of this
>> hostname:
>> >
>> > download.wisselkoersenvoorjeadministratie.nl
>> >
>> > Our FreeIPA DNS servers return SERVFAIL for that particular hostname.
>> What's funny, after I do a (successful) lookup directly at one of the
>> configured forwarders, 1.1.1.1, resolution works, until the TTL expires.
>> Other hostnames work fine. How can I troubleshoot this?
>>
>> Please have a look at the logs:
>> https://www.freeipa.org/page/Troubleshooting/DNS#Getting_logs
>> There should be some entry at the time you reproduce the issue.
>>
>
> No lines related to named in /var/log/messages.
>
> I set debug logging with 'rndc trace' on the IPA nameserver that's being
> queried and this shows up in named.run when I query the hostname:
>
> 21-Apr-2020 13:07:37.912 fetch:
> download.wisselkoersenvoorjeadministratie.nl/A
> 21-Apr-2020 13:07:37.939 client @0x7fcee8031200 10.100.120.47#36751 (
> download.wisselkoersenvoorjeadministratie.nl): query failed (SERVFAIL)
> for download.wisselkoersenvoorjeadministratie.nl/IN/A at
> ../../../bin/named-pkcs11/query.c:8580
>

Added debug level 3, here's a failed lookup and a successful one (after
lookup @1.1.1.1):

[root@ipa-ams-02 ter]# tail -f /var/named/data/named.run | grep
wisselkoersen
21-Apr-2020 13:16:21.397 client @0x7fcef1c8d350 10.100.120.47#35525 (
download.wisselkoersenvoorjeadministratie.nl): query (cache) '
download.wisselkoersenvoorjeadministratie.nl/A/IN' approved
21-Apr-2020 13:16:21.397 client @0x7fcef1c8d350 10.100.120.47#35525 (
download.wisselkoersenvoorjeadministratie.nl): replace
21-Apr-2020 13:16:21.398 fetch:
download.wisselkoersenvoorjeadministratie.nl/A
21-Apr-2020 13:16:21.421 client @0x7fcef1c8d350 10.100.120.47#35525 (
download.wisselkoersenvoorjeadministratie.nl): query failed (SERVFAIL) for
download.wisselkoersenvoorjeadministratie.nl/IN/A at
../../../bin/named-pkcs11/query.c:8580
21-Apr-2020 13:16:21.422 client @0x7fcef1c8d350 10.100.120.47#35525 (
download.wisselkoersenvoorjeadministratie.nl): error
21-Apr-2020 13:16:21.422 client @0x7fcef1c8d350 10.100.120.47#35525 (
download.wisselkoersenvoorjeadministratie.nl): send
21-Apr-2020 13:16:21.422 client @0x7fcef1c8d350 10.100.120.47#35525 (
download.wisselkoersenvoorjeadministratie.nl): sendto
21-Apr-2020 13:16:21.422 client @0x7fcef1c8d350 10.100.120.47#35525 (
download.wisselkoersenvoorjeadministratie.nl): senddone
21-Apr-2020 13:16:21.422 client @0x7fcef1c8d350 10.100.120.47#35525 (
download.wisselkoersenvoorjeadministratie.nl): next
21-Apr-2020 13:16:21.422 client @0x7fcef1c8d350 10.100.120.47#35525 (
download.wisselkoersenvoorjeadministratie.nl): endrequest
21-Apr-2020 13:16:21.422 fetch completed at
../../../lib/dns-pkcs11/resolver.c:3754 for
download.wisselkoersenvoorjeadministratie.nl/A in 0.023506:
SERVFAIL/success [domain:wisselkoersenvoorjeadministratie.nl
,referral:0,restart:2,qrysent:2,timeout:0,lame:0,quota:0,neterr:0,badresp:2,adberr:0,findfail:0,valfail:0]
^C

[root@ipa-ams-02 ter]# tail -f /var/named/data/named.run | grep
wisselkoersen
21-Apr-2020 13:17:15.389 client @0x7fcef000c580 10.100.120.47#40143 (
download.wisselkoersenvoorjeadministratie.nl): query (cache) '
download.wisselkoersenvoorjeadministratie.nl/A/IN' approved
21-Apr-2020 13:17:15.389 client @0x7fcef000c580 10.100.120.47#40143 (
download.wisselkoersenvoorjeadministratie.nl): replace
21-Apr-2020 13:17:15.389 fetch:
download.wisselkoersenvoorjeadministratie.nl/A
21-Apr-2020 13:17:15.403 fctx 0x7fcee981b0d0(
download.wisselkoersenvoorjeadministratie.nl/A): looking for relevant NSEC3
21-Apr-2020 13:17:15.403 fctx 0x7fcee981b0d0(
download.wisselkoersenvoorjeadministratie.nl/A): NSEC3 proves name does not
exist: 'download.wisselkoersenvoorjeadministratie.nl'
21-Apr-2020 13:17:15.403 fctx 0x7fcee981b0d0(
download.wisselkoersenvoorjeadministratie.nl/A): NSEC3 indicates secure
range
21-Apr-2020 13:17:15.403 client @0x7fcef000c580 10.100.120.47#40143 (
download.wisselkoersenvoorjeadministratie.nl): send
21-Apr-2020 13:17:15.403 client @0x7fcef000c580 10.100.120.47#40143 (
download.wisselkoersenvoorjeadministratie.nl): sendto
21-Apr-2020 13:17:15.403 client @0x7fcef000c580 10.100.120.47#40143 (
download.wisselkoersenvoorjeadministratie.nl): senddone
21-Apr-2020 13:17:15.403 client @0x7fcef000c580 10.100.120.47#40143 (
download.wisselkoersenvoorjeadministratie.nl): next
21-Apr-2020 13:17:15.403 client @0x7fcef000c580 10.100.120.47#40143 (
download.wisselkoersenvoorjeadministratie.nl): endrequest

[Freeipa-users] Re: SERVFAIL for one hostname

[Tiemen Ruiten via FreeIPA-users]

Hello,

On Tue, Apr 21, 2020 at 12:46 PM François Cami  wrote:

> Hi,
>
> On Tue, Apr 21, 2020 at 12:19 PM Tiemen Ruiten via FreeIPA-users
>  wrote:
> >
> > Hello,
> >
> > Since a few days ago, we're having issues with resolution of this
> hostname:
> >
> > download.wisselkoersenvoorjeadministratie.nl
> >
> > Our FreeIPA DNS servers return SERVFAIL for that particular hostname.
> What's funny, after I do a (successful) lookup directly at one of the
> configured forwarders, 1.1.1.1, resolution works, until the TTL expires.
> Other hostnames work fine. How can I troubleshoot this?
>
> Please have a look at the logs:
> https://www.freeipa.org/page/Troubleshooting/DNS#Getting_logs
> There should be some entry at the time you reproduce the issue.
>

No lines related to named in /var/log/messages.

I set debug logging with 'rndc trace' on the IPA nameserver that's being
queried and this shows up in named.run when I query the hostname:

21-Apr-2020 13:07:37.912 fetch:
download.wisselkoersenvoorjeadministratie.nl/A
21-Apr-2020 13:07:37.939 client @0x7fcee8031200 10.100.120.47#36751 (
download.wisselkoersenvoorjeadministratie.nl): query failed (SERVFAIL) for
download.wisselkoersenvoorjeadministratie.nl/IN/A at
../../../bin/named-pkcs11/query.c:8580


-- 
Tiemen Ruiten
Infrastructure Engineer
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: SERVFAIL for one hostname

[Tiemen Ruiten via FreeIPA-users]

Hello,

On Tue, Apr 21, 2020 at 1:20 PM Tiemen Ruiten  wrote:

> On Tue, Apr 21, 2020 at 1:10 PM Tiemen Ruiten 
> wrote:
>
>> Hello,
>>
>> On Tue, Apr 21, 2020 at 12:46 PM François Cami  wrote:
>>
>>> Hi,
>>>
>>> On Tue, Apr 21, 2020 at 12:19 PM Tiemen Ruiten via FreeIPA-users
>>>  wrote:
>>> >
>>> > Hello,
>>> >
>>> > Since a few days ago, we're having issues with resolution of this
>>> hostname:
>>> >
>>> > download.wisselkoersenvoorjeadministratie.nl
>>> >
>>> > Our FreeIPA DNS servers return SERVFAIL for that particular hostname.
>>> What's funny, after I do a (successful) lookup directly at one of the
>>> configured forwarders, 1.1.1.1, resolution works, until the TTL expires.
>>> Other hostnames work fine. How can I troubleshoot this?
>>>
>>> Please have a look at the logs:
>>> https://www.freeipa.org/page/Troubleshooting/DNS#Getting_logs
>>> There should be some entry at the time you reproduce the issue.
>>>
>>
>> No lines related to named in /var/log/messages.
>>
>> I set debug logging with 'rndc trace' on the IPA nameserver that's being
>> queried and this shows up in named.run when I query the hostname:
>>
>> 21-Apr-2020 13:07:37.912 fetch:
>> download.wisselkoersenvoorjeadministratie.nl/A
>> 21-Apr-2020 13:07:37.939 client @0x7fcee8031200 10.100.120.47#36751 (
>> download.wisselkoersenvoorjeadministratie.nl): query failed (SERVFAIL)
>> for download.wisselkoersenvoorjeadministratie.nl/IN/A at
>> ../../../bin/named-pkcs11/query.c:8580
>>
>
> Added debug level 3, here's a failed lookup and a successful one (after
> lookup @1.1.1.1):
>
> [root@ipa-ams-02 ter]# tail -f /var/named/data/named.run | grep
> wisselkoersen
> 21-Apr-2020 13:16:21.397 client @0x7fcef1c8d350 10.100.120.47#35525 (
> download.wisselkoersenvoorjeadministratie.nl): query (cache) '
> download.wisselkoersenvoorjeadministratie.nl/A/IN' approved
> 21-Apr-2020 13:16:21.397 client @0x7fcef1c8d350 10.100.120.47#35525 (
> download.wisselkoersenvoorjeadministratie.nl): replace
> 21-Apr-2020 13:16:21.398 fetch:
> download.wisselkoersenvoorjeadministratie.nl/A
> 21-Apr-2020 13:16:21.421 client @0x7fcef1c8d350 10.100.120.47#35525 (
> download.wisselkoersenvoorjeadministratie.nl): query failed (SERVFAIL)
> for download.wisselkoersenvoorjeadministratie.nl/IN/A at
> ../../../bin/named-pkcs11/query.c:8580
> 21-Apr-2020 13:16:21.422 client @0x7fcef1c8d350 10.100.120.47#35525 (
> download.wisselkoersenvoorjeadministratie.nl): error
> 21-Apr-2020 13:16:21.422 client @0x7fcef1c8d350 10.100.120.47#35525 (
> download.wisselkoersenvoorjeadministratie.nl): send
> 21-Apr-2020 13:16:21.422 client @0x7fcef1c8d350 10.100.120.47#35525 (
> download.wisselkoersenvoorjeadministratie.nl): sendto
> 21-Apr-2020 13:16:21.422 client @0x7fcef1c8d350 10.100.120.47#35525 (
> download.wisselkoersenvoorjeadministratie.nl): senddone
> 21-Apr-2020 13:16:21.422 client @0x7fcef1c8d350 10.100.120.47#35525 (
> download.wisselkoersenvoorjeadministratie.nl): next
> 21-Apr-2020 13:16:21.422 client @0x7fcef1c8d350 10.100.120.47#35525 (
> download.wisselkoersenvoorjeadministratie.nl): endrequest
> 21-Apr-2020 13:16:21.422 fetch completed at
> ../../../lib/dns-pkcs11/resolver.c:3754 for
> download.wisselkoersenvoorjeadministratie.nl/A in 0.023506:
> SERVFAIL/success [domain:wisselkoersenvoorjeadministratie.nl
> ,referral:0,restart:2,qrysent:2,timeout:0,lame:0,quota:0,neterr:0,badresp:2,adberr:0,findfail:0,valfail:0]
> ^C
>
> [root@ipa-ams-02 ter]# tail -f /var/named/data/named.run | grep
> wisselkoersen
> 21-Apr-2020 13:17:15.389 client @0x7fcef000c580 10.100.120.47#40143 (
> download.wisselkoersenvoorjeadministratie.nl): query (cache) '
> download.wisselkoersenvoorjeadministratie.nl/A/IN' approved
> 21-Apr-2020 13:17:15.389 client @0x7fcef000c580 10.100.120.47#40143 (
> download.wisselkoersenvoorjeadministratie.nl): replace
> 21-Apr-2020 13:17:15.389 fetch:
> download.wisselkoersenvoorjeadministratie.nl/A
> 21-Apr-2020 13:17:15.403 fctx 0x7fcee981b0d0(
> download.wisselkoersenvoorjeadministratie.nl/A): looking for relevant
> NSEC3
> 21-Apr-2020 13:17:15.403 fctx 0x7fcee981b0d0(
> download.wisselkoersenvoorjeadministratie.nl/A): NSEC3 proves name does
> not exist: 'download.wisselkoersenvoorjeadministratie.nl'
> 21-Apr-2020 13:17:15.403 fctx 0x7fcee981b0d0(
> download.wisselkoersenvoorjeadministratie.nl/A): NSEC3 indicates secure
> range
> 21-Apr-2020 13:17:15.403 client @0x7fcef000c580 10.100.120.47#40143 (
> download.wisselkoersenvoorjeadministratie.nl): send
> 21-Apr-2020 13:17:15.403 cli

[Freeipa-users] Re: SERVFAIL for one hostname

[Tiemen Ruiten via FreeIPA-users]

Hello Petr,

Thank you for the pointers. Even without DNSSEC validation, the query
doesn't return the A-record. Delv also returns SERVFAIL. What I do see at
DNSViz
,
is "NSEC3 proving non-existence of
download.wisselkoersenvoorjeadministratie". That doesn't look normal, if I
compare it with mijn.ing.nl (hostname of a major bank in NL) there is no
such output. I'll try to contact the domain administrators and get them to
fix it

I tried to set the NTA, but it also didn't make a difference. Is there any
other way I could semi-permanently (until the domain administrators fix it)
work around this error?

On Wed, Apr 29, 2020 at 11:52 AM Petr Menšík via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

> Hi Tiemen,
>
> it might help you to use dig and delv to debug dns related issues.
> SERVFAIL is quite often some issue in DNSSEC validation. To ensure
> validation is reponsible, try just:
>
> dig +cd download.wisselkoersenvoorjeadministratie.nl
>
> It it succeeds, validation is responsible. Quite good tool to discover
> what is wrong in that is delv. Use +vtrace to get details. If your server
> provides recursive service, try targetting it with @127.0.0.1.
>
> delv +cd +vtrace @127.0.0.1
> download.wisselkoersenvoorjeadministratie.nl
>
> If it tells you fully validated, it is ok. Try removing +cd. When it still
> validates, bind should get the same results. Only cached records may
> produce different results.
>
> Try flushing cache under that domain:
>
> rndc flushtree wisselkoersenvoorjeadministratie.nl
>
> In case owner of that domain fixed the signature, it might help. If this
> did not help and you are quite sure this is uninteded error, temporary
> validation exception could be set. Before you do it, you should be
> confident noone tried to push you wrong answer into your cache. Usually, it
> should be error on domain server's that its operator had not yet fixed.
>
> rndc nta wisselkoersenvoorjeadministratie.nl
>
> Note NTA is time limited for a reason. Correct is fixing it on
> authoritative servers and flushing just cached tree. Check man rndc for
> details.
>
> named-pkcs11 trace logs would get you similar messages to delv. But I find
> delv easier to use if possible.
>
> Validation of www.regenboog-lelystad.nl. failed few minutes ago to me,
> but seems to be fixed now.
>
> Regards,
> Petr
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
>


-- 
Tiemen Ruiten
Infrastructure Engineer
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: pki-tomcatd fails to start with LDAP error authentication failed (48)

[Tiemen Ruiten via FreeIPA-users]

Hello,

I had this same problem. After the most recent update I was getting
> Authentication Failed (48) in the tomcat debug log during the database
> upgrade. Rolling back 389-ds-base from 1.4.3.16-16 to 1.4.3.16-13 resolved
> that issue. Thank you.
>
>
>> Try downgrading 389-ds-base.
>>
>>
Thanks, did that and problem solved.

-- 
Tiemen Ruiten
Infrastructure Engineer
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Freeipa-users] pki-tomcatd fails to start with LDAP error authentication failed (48)

[Tiemen Ruiten via FreeIPA-users]

Hello,

On a newly installed CentOS 8 IPA master (a few days ago), the
pki-tomcatd@pki-tomcat service fails to start and logs LDAP authentication
failed (48) in /var/log/pki/pki-tomcat/ca/debug.2021-07-01.log. See below.
This happened after I dnf upgraded the master and replica at the same time,
my mistake.

I've gone through the troubleshooting steps described here:
https://floblanc.wordpress.com/2017/09/11/troubleshooting-freeipa-pki-tomcatd-fails-to-start/
but all certificates appear to be correct.

What else can I do?

RPM versions:
[root@ipa-01 ca]# rpm -qa | grep ipa
ipa-healthcheck-0.7-3.module_el8.5.0+750+c59b186b.noarch
python3-libipa_hbac-2.4.0-9.el8_4.1.x86_64
sssd-ipa-2.4.0-9.el8_4.1.x86_64
python3-ipalib-4.9.2-4.module_el8.4.0+846+96522ed7.noarch
ipa-server-trust-ad-4.9.2-4.module_el8.4.0+846+96522ed7.x86_64
centos-logos-ipa-85.8-1.el8.noarch
ipa-healthcheck-core-0.7-3.module_el8.5.0+750+c59b186b.noarch
ipa-client-common-4.9.2-4.module_el8.4.0+846+96522ed7.noarch
ipa-selinux-4.9.2-4.module_el8.4.0+846+96522ed7.noarch
ipa-server-4.9.2-4.module_el8.4.0+846+96522ed7.x86_64
python3-ipaclient-4.9.2-4.module_el8.4.0+846+96522ed7.noarch
python3-ipaserver-4.9.2-4.module_el8.4.0+846+96522ed7.noarch
ipa-server-common-4.9.2-4.module_el8.4.0+846+96522ed7.noarch
libipa_hbac-2.4.0-9.el8_4.1.x86_64
ipa-common-4.9.2-4.module_el8.4.0+846+96522ed7.noarch
ipa-server-dns-4.9.2-4.module_el8.4.0+846+96522ed7.noarch
ipa-client-4.9.2-4.module_el8.4.0+846+96522ed7.x86_64


<...>
2021-07-01 17:28:20 [main] INFO: CMSEngine: initializing password store
2021-07-01 17:28:20 [main] INFO: CMSEngine: initializing password store for
internaldb
2021-07-01 17:28:20 [main] INFO: CMSEngine: initializing password store for
replicationdb
2021-07-01 17:28:20 [main] INFO: CMSEngine: Java version: 1.8.0_292
2021-07-01 17:28:20 [main] INFO: CMSEngine: security providers:
2021-07-01 17:28:20 [main] INFO: PluginRegistry: Loading plugin registry
from /var/lib/pki/pki-tomcat/conf/ca/registry.cfg
2021-07-01 17:28:21 [main] SEVERE: LdapBoundConnFactory: Unable to connect
to LDAP server: Authentication failed
netscape.ldap.LDAPException: Authentication failed (48)
at netscape.ldap.LDAPSaslBind.checkForSASLBindCompletion(Unknown
Source)
at netscape.ldap.LDAPSaslBind.bind(Unknown Source)
at netscape.ldap.LDAPSaslBind.bind(Unknown Source)
at netscape.ldap.LDAPConnection.authenticate(Unknown Source)
at netscape.ldap.LDAPConnection.authenticate(Unknown Source)
at netscape.ldap.LDAPConnection.checkClientAuth(Unknown Source)
at netscape.ldap.LDAPConnection.connect(Unknown Source)
at netscape.ldap.LDAPConnection.connect(Unknown Source)
at netscape.ldap.LDAPConnection.connect(Unknown Source)
at
com.netscape.cmscore.ldapconn.LdapBoundConnection.(LdapBoundConnection.java:105)
at
com.netscape.cmscore.ldapconn.LdapBoundConnFactory.makeConnection(LdapBoundConnFactory.java:284)
at
com.netscape.cmscore.ldapconn.LdapBoundConnFactory.init(LdapBoundConnFactory.java:260)
at
com.netscape.cmscore.ldapconn.LdapBoundConnFactory.init(LdapBoundConnFactory.java:223)
at
com.netscape.cmscore.ldapconn.LdapBoundConnFactory.init(LdapBoundConnFactory.java:192)
at org.dogtagpki.server.ca.CAEngine.initDatabase(CAEngine.java:186)
at com.netscape.cmscore.apps.CMSEngine.start(CMSEngine.java:1002)
at
com.netscape.cmscore.apps.CMSEngine.contextInitialized(CMSEngine.java:1643)
at
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4685)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5146)
at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:717)
at
org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:129)
at
org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:150)
at
org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:140)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:688)
at
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:705)
at
org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:631)
at
org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1831)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
at
java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:112)
at
org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:526)
at

[Freeipa-users] ipa user-del fails with `ipa: ERROR: non-public: KeyError: 'ipauniqueid'`

[Tiemen Ruiten via FreeIPA-users]

Hello,

OS: up-to-date CentOS 8, ipa
versions 4.9.2-4.module_el8.4.0+846+96522ed7.x86_64

I'm getting a traceback in the httpd log when I try to delete a test user.
See below. It appears the ipaUniqueId is missing for the user? I can see
the user with ipa user-show:

[root@ipa-02 /]# ipa user-show tet
  User login: tet
  First name:
  Last name:
  Account disabled: True
  Password: False
  Kerberos keys available: False

But not with ipa user-find:

[root@ipa-02 /]# ipa user-find tet
---
0 users matched
---

Number of entries returned 0


It also isn't visible in the web interface. How can I delete this user?

[Tue Aug 03 12:22:02.769800 2021] [:warn] [pid 69915:tid 139855196710656]
[client 10.100.120.13:34894] failed to set perms (3140) on file
(/run/ipa/ccaches/ad...@i.tech-lab.io-59LxxO)!, referer:
https://ipa-02.i.tech-lab.io/ipa/xml
[Tue Aug 03 12:22:02.786834 2021] [wsgi:error] [pid 69340:tid
139855208355584] [remote 10.100.120.13:34894] ipa: INFO:
[jsonserver_session] ad...@i.tech-lab.io: ping(): SUCCESS
[Tue Aug 03 12:22:02.790684 2021] [:warn] [pid 69915:tid 139855179925248]
[client 10.100.120.13:34894] failed to set perms (3140) on file
(/run/ipa/ccaches/ad...@i.tech-lab.io-59LxxO)!, referer:
https://ipa-02.i.tech-lab.io/ipa/xml
*[Tue Aug 03 12:22:03.126949 2021] [wsgi:error] [pid 69338:tid
139855208355584] [remote 10.100.120.13:34894 ]
ipa: ERROR: non-public: KeyError: 'ipauniqueid'*
[Tue Aug 03 12:22:03.127067 2021] [wsgi:error] [pid 69338:tid
139855208355584] [remote 10.100.120.13:34894] Traceback (most recent call
last):
[Tue Aug 03 12:22:03.127075 2021] [wsgi:error] [pid 69338:tid
139855208355584] [remote 10.100.120.13:34894]   File
"/usr/lib/python3.6/site-packages/ipaserver/rpcserver.py", line 397, in
wsgi_execute
[Tue Aug 03 12:22:03.127081 2021] [wsgi:error] [pid 69338:tid
139855208355584] [remote 10.100.120.13:34894] result = command(*args,
**options)
[Tue Aug 03 12:22:03.127086 2021] [wsgi:error] [pid 69338:tid
139855208355584] [remote 10.100.120.13:34894]   File
"/usr/lib/python3.6/site-packages/ipalib/frontend.py", line 471, in __call__
[Tue Aug 03 12:22:03.127092 2021] [wsgi:error] [pid 69338:tid
139855208355584] [remote 10.100.120.13:34894] return
self.__do_call(*args, **options)
[Tue Aug 03 12:22:03.127133 2021] [wsgi:error] [pid 69338:tid
139855208355584] [remote 10.100.120.13:34894]   File
"/usr/lib/python3.6/site-packages/ipalib/frontend.py", line 499, in
__do_call
[Tue Aug 03 12:22:03.127140 2021] [wsgi:error] [pid 69338:tid
139855208355584] [remote 10.100.120.13:34894] ret = self.run(*args,
**options)
[Tue Aug 03 12:22:03.127145 2021] [wsgi:error] [pid 69338:tid
139855208355584] [remote 10.100.120.13:34894]   File
"/usr/lib/python3.6/site-packages/ipalib/frontend.py", line 821, in run
[Tue Aug 03 12:22:03.127150 2021] [wsgi:error] [pid 69338:tid
139855208355584] [remote 10.100.120.13:34894] return
self.execute(*args, **options)
[Tue Aug 03 12:22:03.127155 2021] [wsgi:error] [pid 69338:tid
139855208355584] [remote 10.100.120.13:34894]   File
"/usr/lib/python3.6/site-packages/ipaserver/plugins/user.py", line 802, in
execute
[Tue Aug 03 12:22:03.127160 2021] [wsgi:error] [pid 69338:tid
139855208355584] [remote 10.100.120.13:34894] return super(user_del,
self).execute(*keys, **options)
[Tue Aug 03 12:22:03.127165 2021] [wsgi:error] [pid 69338:tid
139855208355584] [remote 10.100.120.13:34894]   File
"/usr/lib/python3.6/site-packages/ipaserver/plugins/baseldap.py", line
1678, in execute
[Tue Aug 03 12:22:03.127171 2021] [wsgi:error] [pid 69338:tid
139855208355584] [remote 10.100.120.13:34894] delete_entry(pkey)
[Tue Aug 03 12:22:03.127176 2021] [wsgi:error] [pid 69338:tid
139855208355584] [remote 10.100.120.13:34894]   File
"/usr/lib/python3.6/site-packages/ipaserver/plugins/baseldap.py", line
1629, in delete_entry
[Tue Aug 03 12:22:03.127181 2021] [wsgi:error] [pid 69338:tid
139855208355584] [remote 10.100.120.13:34894] dn = callback(self, ldap,
dn, *nkeys, **options)
[Tue Aug 03 12:22:03.127186 2021] [wsgi:error] [pid 69338:tid
139855208355584] [remote 10.100.120.13:34894]   File
"/usr/lib/python3.6/site-packages/ipaserver/plugins/user.py", line 759, in
pre_callback
[Tue Aug 03 12:22:03.127191 2021] [wsgi:error] [pid 69338:tid
139855208355584] [remote 10.100.120.13:34894]
remove_ipaobject_overrides(self.obj.backend, self.obj.api, dn)
[Tue Aug 03 12:22:03.127197 2021] [wsgi:error] [pid 69338:tid
139855208355584] [remote 10.100.120.13:34894]   File
"/usr/lib/python3.6/site-packages/ipaserver/plugins/idviews.py", line 700,
in remove_ipaobject_overrides
[Tue Aug 03 12:22:03.127202 2021] [wsgi:error] [pid 69338:tid
139855208355584] [remote 10.100.120.13:34894] object_uuid =
entry.single_value['ipaUniqueID']
[Tue Aug 03 12:22:03.127207 2021] [wsgi:error] [pid 69338:tid
139855208355584] [remote 10.100.120.13:34894]   File