[Freeipa-users] Re: kpasswd: Preauthentication failed getting initial ticket

[Alexander Bokovoy via FreeIPA-users]

On ke, 04 heinä 2018, lune voo via FreeIPA-users wrote:

I will try to reproduce the problem interactively in python.


I meant in shell, to rule out any issues outside your python code.



Lune



Le mer. 4 juil. 2018 à 07:20, Alexander Bokovoy  a
écrit :


On ke, 04 heinä 2018, lune voo wrote:
>Hello Alexander.
>
>Thanks for the answer.
>
>Otp stands for one time password.
>
>In fact in order to set a password for a user, I do first a ipa passwd
>using ipa python library.
So, your code is equivalent to

kinit admin
ipa passwd test-user
kpasswd test-user

?

I.e. there is no 2FA involved and what you call 'otp' is only reflecting
the fact that any non-user-initiated password change forces that user to
change their password, so 'ipa passwd test-user' as admin means
'test-user' password has to be changed and becomes effectively a one
time password set by admin.

Is that a correct assessment?


>The otp is good normally.
Can you demonstrate things not working in a console, interactively?

>And the kpasswd password should be good also except if ipa kdc dont like
>some special characters ?
There is no limits on what Kerberos KDC considers a 'password' as that
could be a bunch of random bytes.

>
>Lune.
>
>
>Le mar. 3 juil. 2018 à 17:49, Alexander Bokovoy  a
>écrit :
>
>> On ti, 03 heinä 2018, lune voo via FreeIPA-users wrote:
>> >Hello !
>> >
>> >I contact you because I encounter a problem when I use kpasswd using
>> python
>> >popen function.
>> >I use freeipa 3.0 and python 2.6.6.
>> >
>> >Here is what I do in python :
>> >
>> >input_process = otp + '\n' + password + '\n' + password
>> Here you provide otp (what is this? A 2FA token value?), password and
>> password.
>>
>> >cmd = 'kpasswd %s' % user_login
>> >cmd_and_args = shlex.split(cmd)
>> >p = Popen(cmd_and_args, stdout=PIPE, stdin=PIPE, stderr=STDOUT)
>> >(output, error) = p.communicate(input=input_process)
>> >
>> >
>> >Before doing that, I performed the following command in order to have
more
>> >logs :
>> >export KRB5_TRACE=/dev/stdout
>> >
>> >And here is what I see in the logs :
>> >###
>> >[47700] 1530630765.610794: Getting initial credentials for
>> test_user@MYREALM
>> >[47700] 1530630765.610945: FAST armor ccache: FILE:/tmp/krb5cc_testuser
>> >[47700] 1530630765.610998: Retrieving admin@MYREALM ->
>> >krb5_ccache_conf_data/fast_avail/krbtgt\/MYREALM\@MYREALM@X-CACHECONF:
>> from
>> >FILE:/tmp/krb5cc_testuser with result: 0/Success
>> >[47700] 1530630765.611003: Read config in FILE:/tmp/krb5cc_testuser for
>> >krbtgt/MYREALM@MYREALM: fast_avail: yes
>> >[47700] 1530630765.611006: Using FAST due to armor ccache negotiation
>> result
>> >[47700] 1530630765.611016: Getting credentials admin@MYREALM ->
>> >krbtgt/MYREALM@MYREALM using ccache FILE:/tmp/krb5cc_testuser
>> >[47700] 1530630765.611044: Retrieving admin@MYREALM ->
>> >krbtgt/MYREALM@MYREALM from FILE:/tmp/krb5cc_testuser with result:
>> 0/Success
>> >[47700] 1530630765.611061: Armor ccache sesion key: aes256-cts/2559
>> >[47700] 1530630765.611089: Creating authenticator for admin@MYREALM ->
>> >krbtgt/MYREALM@MYREALM, seqnum 0, subkey aes256-cts/7F39, session key
>> >aes256-cts/2559
>> >[47700] 1530630765.611168: FAST armor key: aes256-cts/79AB
>> >[47700] 1530630765.611179: Setting initial creds service to
>> kadmin/changepw
>> >[47700] 1530630765.611184: FAST armor ccache: FILE:/tmp/krb5cc_testuser
>> >[47700] 1530630765.611208: Retrieving admin@MYREALM ->
>> >krb5_ccache_conf_data/fast_avail/krbtgt\/MYREALM\@MYREALM@X-CACHECONF:
>> from
>> >FILE:/tmp/krb5cc_testuser with result: 0/Success
>> >[47700] 1530630765.611212: Read config in FILE:/tmp/krb5cc_testuser for
>> >krbtgt/MYREALM@MYREALM: fast_avail: yes
>> >[47700] 1530630765.611213: Using FAST due to armor ccache negotiation
>> result
>> >[47700] 1530630765.611219: Getting credentials admin@MYREALM ->
>> >krbtgt/MYREALM@MYREALM using ccache FILE:/tmp/krb5cc_testuser
>> >[47700] 1530630765.611240: Retrieving admin@MYREALM ->
>> >krbtgt/MYREALM@MYREALM from FILE:/tmp/krb5cc_testuser with result:
>> 0/Success
>> >[47700] 1530630765.611245: Armor ccache sesion key: aes256-cts/2559
>> >[47700] 1530630765.611256: Creating authenticator for admin@MYREALM ->
>> >krbtgt/MYREALM@MYREALM, seqnum 0, subkey aes256-cts/2BFD, session key
>> >aes256-cts/2559
>> >[47700] 1530630765.611288: FAST armor key: aes256-cts/62C4
>> >[47700] 1530630765.611299: Encoding request body and padata into FAST
>> >request
>> >[47700] 1530630765.611333: Sending request (1019 bytes) to MYREALM
>> >[47700] 1530630765.611418: Resolving hostname ipamasterhostname
>> >[47700] 1530630765.611608: Initiating TCP connection to stream
>> >ipamasterIP:88
>> >[47700] 1530630765.611769: Sending TCP request to stream ipamasterIP:88
>> >[47700] 1530630765.675154: Received answer from stream ipamasterIP:88
>> >[47700] 1530630765.675208: Response was from master KDC
>> >[47700] 1530630765.675238: Received error from KDC:
-1765328359/Additional
>> >pre-authentication required
>> 

[Freeipa-users] Re: kpasswd: Preauthentication failed getting initial ticket

[lune voo via FreeIPA-users]

I will try to reproduce the problem interactively in python.

Lune



Le mer. 4 juil. 2018 à 07:20, Alexander Bokovoy  a
écrit :

> On ke, 04 heinä 2018, lune voo wrote:
> >Hello Alexander.
> >
> >Thanks for the answer.
> >
> >Otp stands for one time password.
> >
> >In fact in order to set a password for a user, I do first a ipa passwd
> >using ipa python library.
> So, your code is equivalent to
>
> kinit admin
> ipa passwd test-user
> kpasswd test-user
>
> ?
>
> I.e. there is no 2FA involved and what you call 'otp' is only reflecting
> the fact that any non-user-initiated password change forces that user to
> change their password, so 'ipa passwd test-user' as admin means
> 'test-user' password has to be changed and becomes effectively a one
> time password set by admin.
>
> Is that a correct assessment?
>
>
> >The otp is good normally.
> Can you demonstrate things not working in a console, interactively?
>
> >And the kpasswd password should be good also except if ipa kdc dont like
> >some special characters ?
> There is no limits on what Kerberos KDC considers a 'password' as that
> could be a bunch of random bytes.
>
> >
> >Lune.
> >
> >
> >Le mar. 3 juil. 2018 à 17:49, Alexander Bokovoy  a
> >écrit :
> >
> >> On ti, 03 heinä 2018, lune voo via FreeIPA-users wrote:
> >> >Hello !
> >> >
> >> >I contact you because I encounter a problem when I use kpasswd using
> >> python
> >> >popen function.
> >> >I use freeipa 3.0 and python 2.6.6.
> >> >
> >> >Here is what I do in python :
> >> >
> >> >input_process = otp + '\n' + password + '\n' + password
> >> Here you provide otp (what is this? A 2FA token value?), password and
> >> password.
> >>
> >> >cmd = 'kpasswd %s' % user_login
> >> >cmd_and_args = shlex.split(cmd)
> >> >p = Popen(cmd_and_args, stdout=PIPE, stdin=PIPE, stderr=STDOUT)
> >> >(output, error) = p.communicate(input=input_process)
> >> >
> >> >
> >> >Before doing that, I performed the following command in order to have
> more
> >> >logs :
> >> >export KRB5_TRACE=/dev/stdout
> >> >
> >> >And here is what I see in the logs :
> >> >###
> >> >[47700] 1530630765.610794: Getting initial credentials for
> >> test_user@MYREALM
> >> >[47700] 1530630765.610945: FAST armor ccache: FILE:/tmp/krb5cc_testuser
> >> >[47700] 1530630765.610998: Retrieving admin@MYREALM ->
> >> >krb5_ccache_conf_data/fast_avail/krbtgt\/MYREALM\@MYREALM@X-CACHECONF:
> >> from
> >> >FILE:/tmp/krb5cc_testuser with result: 0/Success
> >> >[47700] 1530630765.611003: Read config in FILE:/tmp/krb5cc_testuser for
> >> >krbtgt/MYREALM@MYREALM: fast_avail: yes
> >> >[47700] 1530630765.611006: Using FAST due to armor ccache negotiation
> >> result
> >> >[47700] 1530630765.611016: Getting credentials admin@MYREALM ->
> >> >krbtgt/MYREALM@MYREALM using ccache FILE:/tmp/krb5cc_testuser
> >> >[47700] 1530630765.611044: Retrieving admin@MYREALM ->
> >> >krbtgt/MYREALM@MYREALM from FILE:/tmp/krb5cc_testuser with result:
> >> 0/Success
> >> >[47700] 1530630765.611061: Armor ccache sesion key: aes256-cts/2559
> >> >[47700] 1530630765.611089: Creating authenticator for admin@MYREALM ->
> >> >krbtgt/MYREALM@MYREALM, seqnum 0, subkey aes256-cts/7F39, session key
> >> >aes256-cts/2559
> >> >[47700] 1530630765.611168: FAST armor key: aes256-cts/79AB
> >> >[47700] 1530630765.611179: Setting initial creds service to
> >> kadmin/changepw
> >> >[47700] 1530630765.611184: FAST armor ccache: FILE:/tmp/krb5cc_testuser
> >> >[47700] 1530630765.611208: Retrieving admin@MYREALM ->
> >> >krb5_ccache_conf_data/fast_avail/krbtgt\/MYREALM\@MYREALM@X-CACHECONF:
> >> from
> >> >FILE:/tmp/krb5cc_testuser with result: 0/Success
> >> >[47700] 1530630765.611212: Read config in FILE:/tmp/krb5cc_testuser for
> >> >krbtgt/MYREALM@MYREALM: fast_avail: yes
> >> >[47700] 1530630765.611213: Using FAST due to armor ccache negotiation
> >> result
> >> >[47700] 1530630765.611219: Getting credentials admin@MYREALM ->
> >> >krbtgt/MYREALM@MYREALM using ccache FILE:/tmp/krb5cc_testuser
> >> >[47700] 1530630765.611240: Retrieving admin@MYREALM ->
> >> >krbtgt/MYREALM@MYREALM from FILE:/tmp/krb5cc_testuser with result:
> >> 0/Success
> >> >[47700] 1530630765.611245: Armor ccache sesion key: aes256-cts/2559
> >> >[47700] 1530630765.611256: Creating authenticator for admin@MYREALM ->
> >> >krbtgt/MYREALM@MYREALM, seqnum 0, subkey aes256-cts/2BFD, session key
> >> >aes256-cts/2559
> >> >[47700] 1530630765.611288: FAST armor key: aes256-cts/62C4
> >> >[47700] 1530630765.611299: Encoding request body and padata into FAST
> >> >request
> >> >[47700] 1530630765.611333: Sending request (1019 bytes) to MYREALM
> >> >[47700] 1530630765.611418: Resolving hostname ipamasterhostname
> >> >[47700] 1530630765.611608: Initiating TCP connection to stream
> >> >ipamasterIP:88
> >> >[47700] 1530630765.611769: Sending TCP request to stream ipamasterIP:88
> >> >[47700] 1530630765.675154: Received answer from stream ipamasterIP:88
> >> >[47700] 1530630765.675208: Response was from master KDC
> >> >[47700] 

[Freeipa-users] Re: AD user shown id command but visible for ldapsearch

[Alexander Bokovoy via FreeIPA-users]

On ke, 04 heinä 2018, Pieter Baele via FreeIPA-users wrote:

Hi,

On a test FreeIPA environment (4.5.0-22), a user is shown using the id
command, so ID Override is working as well.
id x...@accmsnet.railb.be
uid=8028(x...@accmsnet.railb.be) gid=4030(ucc)
groups=4030(ucc),702800513(domain us...@accmsnet.railb.be
),131849(ad_users)

However this particular (AD) user is not shown using an ldapsearch in the
compat
ldapsearch -Y GSSAPI -b cn=compat,dc=accnix,dc=infrabel,dc=be
'(&(objectClass=posixAccount)(uid=))'

# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: (&(objectClass=posixAccount)(uid=mcj7700))

Here uid is non-fully qualified. A trigger in the compat tree plugin is
built around using fully qualified user names for AD users, e.g.
(uid=mcj...@accmsnet.railb.be).

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/ZX332Y5KXHOPEPAJGZBDUYIDET7Q33RI/

[Freeipa-users] AIX 7.x with sudo, netgroups, LDAP and Kerberos

[Pieter Baele via FreeIPA-users]

I have currently been assisting an AIX colleague to use IPA as
authentication/authz provider for AIX systems.
That way we are moving to a common platform

We have found some examples on the web (AIX 5.x, AIX 6); information here
and there - but for the moment we still have a few issues.
The proprietary AIX schema extensions would be a nice to have, but are not
required (as I have read in earlier posts)

Has anyone seen a complete working example for a AIX client configuration
for FreeIPA?
Once we have found everything; I'll try to share the information.

-- PieterB
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/YC4HJU7CBR6DX2LGPQZSEZN5QKJV6DC3/

[Freeipa-users] Re: kpasswd: Preauthentication failed getting initial ticket

[Alexander Bokovoy via FreeIPA-users]

On ke, 04 heinä 2018, lune voo wrote:

Hello Alexander.

Thanks for the answer.

Otp stands for one time password.

In fact in order to set a password for a user, I do first a ipa passwd
using ipa python library.

So, your code is equivalent to

kinit admin
ipa passwd test-user
kpasswd test-user

?

I.e. there is no 2FA involved and what you call 'otp' is only reflecting
the fact that any non-user-initiated password change forces that user to
change their password, so 'ipa passwd test-user' as admin means
'test-user' password has to be changed and becomes effectively a one
time password set by admin.

Is that a correct assessment?



The otp is good normally.

Can you demonstrate things not working in a console, interactively?


And the kpasswd password should be good also except if ipa kdc dont like
some special characters ?

There is no limits on what Kerberos KDC considers a 'password' as that
could be a bunch of random bytes.



Lune.


Le mar. 3 juil. 2018 à 17:49, Alexander Bokovoy  a
écrit :


On ti, 03 heinä 2018, lune voo via FreeIPA-users wrote:
>Hello !
>
>I contact you because I encounter a problem when I use kpasswd using
python
>popen function.
>I use freeipa 3.0 and python 2.6.6.
>
>Here is what I do in python :
>
>input_process = otp + '\n' + password + '\n' + password
Here you provide otp (what is this? A 2FA token value?), password and
password.

>cmd = 'kpasswd %s' % user_login
>cmd_and_args = shlex.split(cmd)
>p = Popen(cmd_and_args, stdout=PIPE, stdin=PIPE, stderr=STDOUT)
>(output, error) = p.communicate(input=input_process)
>
>
>Before doing that, I performed the following command in order to have more
>logs :
>export KRB5_TRACE=/dev/stdout
>
>And here is what I see in the logs :
>###
>[47700] 1530630765.610794: Getting initial credentials for
test_user@MYREALM
>[47700] 1530630765.610945: FAST armor ccache: FILE:/tmp/krb5cc_testuser
>[47700] 1530630765.610998: Retrieving admin@MYREALM ->
>krb5_ccache_conf_data/fast_avail/krbtgt\/MYREALM\@MYREALM@X-CACHECONF:
from
>FILE:/tmp/krb5cc_testuser with result: 0/Success
>[47700] 1530630765.611003: Read config in FILE:/tmp/krb5cc_testuser for
>krbtgt/MYREALM@MYREALM: fast_avail: yes
>[47700] 1530630765.611006: Using FAST due to armor ccache negotiation
result
>[47700] 1530630765.611016: Getting credentials admin@MYREALM ->
>krbtgt/MYREALM@MYREALM using ccache FILE:/tmp/krb5cc_testuser
>[47700] 1530630765.611044: Retrieving admin@MYREALM ->
>krbtgt/MYREALM@MYREALM from FILE:/tmp/krb5cc_testuser with result:
0/Success
>[47700] 1530630765.611061: Armor ccache sesion key: aes256-cts/2559
>[47700] 1530630765.611089: Creating authenticator for admin@MYREALM ->
>krbtgt/MYREALM@MYREALM, seqnum 0, subkey aes256-cts/7F39, session key
>aes256-cts/2559
>[47700] 1530630765.611168: FAST armor key: aes256-cts/79AB
>[47700] 1530630765.611179: Setting initial creds service to
kadmin/changepw
>[47700] 1530630765.611184: FAST armor ccache: FILE:/tmp/krb5cc_testuser
>[47700] 1530630765.611208: Retrieving admin@MYREALM ->
>krb5_ccache_conf_data/fast_avail/krbtgt\/MYREALM\@MYREALM@X-CACHECONF:
from
>FILE:/tmp/krb5cc_testuser with result: 0/Success
>[47700] 1530630765.611212: Read config in FILE:/tmp/krb5cc_testuser for
>krbtgt/MYREALM@MYREALM: fast_avail: yes
>[47700] 1530630765.611213: Using FAST due to armor ccache negotiation
result
>[47700] 1530630765.611219: Getting credentials admin@MYREALM ->
>krbtgt/MYREALM@MYREALM using ccache FILE:/tmp/krb5cc_testuser
>[47700] 1530630765.611240: Retrieving admin@MYREALM ->
>krbtgt/MYREALM@MYREALM from FILE:/tmp/krb5cc_testuser with result:
0/Success
>[47700] 1530630765.611245: Armor ccache sesion key: aes256-cts/2559
>[47700] 1530630765.611256: Creating authenticator for admin@MYREALM ->
>krbtgt/MYREALM@MYREALM, seqnum 0, subkey aes256-cts/2BFD, session key
>aes256-cts/2559
>[47700] 1530630765.611288: FAST armor key: aes256-cts/62C4
>[47700] 1530630765.611299: Encoding request body and padata into FAST
>request
>[47700] 1530630765.611333: Sending request (1019 bytes) to MYREALM
>[47700] 1530630765.611418: Resolving hostname ipamasterhostname
>[47700] 1530630765.611608: Initiating TCP connection to stream
>ipamasterIP:88
>[47700] 1530630765.611769: Sending TCP request to stream ipamasterIP:88
>[47700] 1530630765.675154: Received answer from stream ipamasterIP:88
>[47700] 1530630765.675208: Response was from master KDC
>[47700] 1530630765.675238: Received error from KDC: -1765328359/Additional
>pre-authentication required
>[47700] 1530630765.675249: Decoding FAST response
>[47700] 1530630765.675311: Processing preauth types: 136, 19, 138, 133,
137
>[47700] 1530630765.675319: Received cookie: MIT
>Password for test_user@MYREALM:
Here you are asked for a password.

>[47700] 1530630765.682884: Preauth module
>encrypted_challenge (138) (flags=1) returned: 0/Success
>[47700] 1530630765.682889: Produced preauth for next request: 133, 138
>[47700] 1530630765.682891: Encoding request body and padata into FAST
>request
>[47700] 

[Freeipa-users] AD user shown id command but visible for ldapsearch

[Pieter Baele via FreeIPA-users]

Hi,

On a test FreeIPA environment (4.5.0-22), a user is shown using the id
command, so ID Override is working as well.
id x...@accmsnet.railb.be
uid=8028(x...@accmsnet.railb.be) gid=4030(ucc)
groups=4030(ucc),702800513(domain us...@accmsnet.railb.be
),131849(ad_users)

However this particular (AD) user is not shown using an ldapsearch in the
compat
ldapsearch -Y GSSAPI -b cn=compat,dc=accnix,dc=infrabel,dc=be
'(&(objectClass=posixAccount)(uid=))'

# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: (&(objectClass=posixAccount)(uid=mcj7700))
# requesting: ALL
#

# search result
search: 4
result: 0 Success

Any idea? This is not happening in our production environment.
I cleared caches, did enable slapi-compat, and even tried adding the
resolution by an ldif to be sure
I did also re-run ipa-adtrust-install

I really don't understand why the AD users are not visible in LDAP

Sincerely Pieter
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/3W4QMCIGIPDUY3V65M2Q723AF3FWRAFP/

[Freeipa-users] Re: kpasswd: Preauthentication failed getting initial ticket

[lune voo via FreeIPA-users]

Hello Alexander.

Thanks for the answer.

Otp stands for one time password.

In fact in order to set a password for a user, I do first a ipa passwd
using ipa python library.

The otp is good normally.

And the kpasswd password should be good also except if ipa kdc dont like
some special characters ?

Lune.


Le mar. 3 juil. 2018 à 17:49, Alexander Bokovoy  a
écrit :

> On ti, 03 heinä 2018, lune voo via FreeIPA-users wrote:
> >Hello !
> >
> >I contact you because I encounter a problem when I use kpasswd using
> python
> >popen function.
> >I use freeipa 3.0 and python 2.6.6.
> >
> >Here is what I do in python :
> >
> >input_process = otp + '\n' + password + '\n' + password
> Here you provide otp (what is this? A 2FA token value?), password and
> password.
>
> >cmd = 'kpasswd %s' % user_login
> >cmd_and_args = shlex.split(cmd)
> >p = Popen(cmd_and_args, stdout=PIPE, stdin=PIPE, stderr=STDOUT)
> >(output, error) = p.communicate(input=input_process)
> >
> >
> >Before doing that, I performed the following command in order to have more
> >logs :
> >export KRB5_TRACE=/dev/stdout
> >
> >And here is what I see in the logs :
> >###
> >[47700] 1530630765.610794: Getting initial credentials for
> test_user@MYREALM
> >[47700] 1530630765.610945: FAST armor ccache: FILE:/tmp/krb5cc_testuser
> >[47700] 1530630765.610998: Retrieving admin@MYREALM ->
> >krb5_ccache_conf_data/fast_avail/krbtgt\/MYREALM\@MYREALM@X-CACHECONF:
> from
> >FILE:/tmp/krb5cc_testuser with result: 0/Success
> >[47700] 1530630765.611003: Read config in FILE:/tmp/krb5cc_testuser for
> >krbtgt/MYREALM@MYREALM: fast_avail: yes
> >[47700] 1530630765.611006: Using FAST due to armor ccache negotiation
> result
> >[47700] 1530630765.611016: Getting credentials admin@MYREALM ->
> >krbtgt/MYREALM@MYREALM using ccache FILE:/tmp/krb5cc_testuser
> >[47700] 1530630765.611044: Retrieving admin@MYREALM ->
> >krbtgt/MYREALM@MYREALM from FILE:/tmp/krb5cc_testuser with result:
> 0/Success
> >[47700] 1530630765.611061: Armor ccache sesion key: aes256-cts/2559
> >[47700] 1530630765.611089: Creating authenticator for admin@MYREALM ->
> >krbtgt/MYREALM@MYREALM, seqnum 0, subkey aes256-cts/7F39, session key
> >aes256-cts/2559
> >[47700] 1530630765.611168: FAST armor key: aes256-cts/79AB
> >[47700] 1530630765.611179: Setting initial creds service to
> kadmin/changepw
> >[47700] 1530630765.611184: FAST armor ccache: FILE:/tmp/krb5cc_testuser
> >[47700] 1530630765.611208: Retrieving admin@MYREALM ->
> >krb5_ccache_conf_data/fast_avail/krbtgt\/MYREALM\@MYREALM@X-CACHECONF:
> from
> >FILE:/tmp/krb5cc_testuser with result: 0/Success
> >[47700] 1530630765.611212: Read config in FILE:/tmp/krb5cc_testuser for
> >krbtgt/MYREALM@MYREALM: fast_avail: yes
> >[47700] 1530630765.611213: Using FAST due to armor ccache negotiation
> result
> >[47700] 1530630765.611219: Getting credentials admin@MYREALM ->
> >krbtgt/MYREALM@MYREALM using ccache FILE:/tmp/krb5cc_testuser
> >[47700] 1530630765.611240: Retrieving admin@MYREALM ->
> >krbtgt/MYREALM@MYREALM from FILE:/tmp/krb5cc_testuser with result:
> 0/Success
> >[47700] 1530630765.611245: Armor ccache sesion key: aes256-cts/2559
> >[47700] 1530630765.611256: Creating authenticator for admin@MYREALM ->
> >krbtgt/MYREALM@MYREALM, seqnum 0, subkey aes256-cts/2BFD, session key
> >aes256-cts/2559
> >[47700] 1530630765.611288: FAST armor key: aes256-cts/62C4
> >[47700] 1530630765.611299: Encoding request body and padata into FAST
> >request
> >[47700] 1530630765.611333: Sending request (1019 bytes) to MYREALM
> >[47700] 1530630765.611418: Resolving hostname ipamasterhostname
> >[47700] 1530630765.611608: Initiating TCP connection to stream
> >ipamasterIP:88
> >[47700] 1530630765.611769: Sending TCP request to stream ipamasterIP:88
> >[47700] 1530630765.675154: Received answer from stream ipamasterIP:88
> >[47700] 1530630765.675208: Response was from master KDC
> >[47700] 1530630765.675238: Received error from KDC: -1765328359/Additional
> >pre-authentication required
> >[47700] 1530630765.675249: Decoding FAST response
> >[47700] 1530630765.675311: Processing preauth types: 136, 19, 138, 133,
> 137
> >[47700] 1530630765.675319: Received cookie: MIT
> >Password for test_user@MYREALM:
> Here you are asked for a password.
>
> >[47700] 1530630765.682884: Preauth module
> >encrypted_challenge (138) (flags=1) returned: 0/Success
> >[47700] 1530630765.682889: Produced preauth for next request: 133, 138
> >[47700] 1530630765.682891: Encoding request body and padata into FAST
> >request
> >[47700] 1530630765.682951: Sending request (1118 bytes) to MYREALM
> >[47700] 1530630765.682967: Resolving hostname ipamasterhostname
> >[47700] 1530630765.683098: Initiating TCP connection to stream
> >ipamasterIP:88
> >[47700] 1530630765.683180: Sending TCP request to stream ipamasterIP:88
> >[47700] 1530630765.756232: Received answer from stream ipamasterIP:88
> >[47700] 1530630765.756302: Response was from master KDC
> >[47700] 1530630765.756321: Received error from 

[Freeipa-users] Re: kpasswd: Preauthentication failed getting initial ticket

[Alexander Bokovoy via FreeIPA-users]

On ti, 03 heinä 2018, lune voo via FreeIPA-users wrote:

Hello !

I contact you because I encounter a problem when I use kpasswd using python
popen function.
I use freeipa 3.0 and python 2.6.6.

Here is what I do in python :

input_process = otp + '\n' + password + '\n' + password

Here you provide otp (what is this? A 2FA token value?), password and
password.


cmd = 'kpasswd %s' % user_login
cmd_and_args = shlex.split(cmd)
p = Popen(cmd_and_args, stdout=PIPE, stdin=PIPE, stderr=STDOUT)
(output, error) = p.communicate(input=input_process)


Before doing that, I performed the following command in order to have more
logs :
export KRB5_TRACE=/dev/stdout

And here is what I see in the logs :
###
[47700] 1530630765.610794: Getting initial credentials for test_user@MYREALM
[47700] 1530630765.610945: FAST armor ccache: FILE:/tmp/krb5cc_testuser
[47700] 1530630765.610998: Retrieving admin@MYREALM ->
krb5_ccache_conf_data/fast_avail/krbtgt\/MYREALM\@MYREALM@X-CACHECONF: from
FILE:/tmp/krb5cc_testuser with result: 0/Success
[47700] 1530630765.611003: Read config in FILE:/tmp/krb5cc_testuser for
krbtgt/MYREALM@MYREALM: fast_avail: yes
[47700] 1530630765.611006: Using FAST due to armor ccache negotiation result
[47700] 1530630765.611016: Getting credentials admin@MYREALM ->
krbtgt/MYREALM@MYREALM using ccache FILE:/tmp/krb5cc_testuser
[47700] 1530630765.611044: Retrieving admin@MYREALM ->
krbtgt/MYREALM@MYREALM from FILE:/tmp/krb5cc_testuser with result: 0/Success
[47700] 1530630765.611061: Armor ccache sesion key: aes256-cts/2559
[47700] 1530630765.611089: Creating authenticator for admin@MYREALM ->
krbtgt/MYREALM@MYREALM, seqnum 0, subkey aes256-cts/7F39, session key
aes256-cts/2559
[47700] 1530630765.611168: FAST armor key: aes256-cts/79AB
[47700] 1530630765.611179: Setting initial creds service to kadmin/changepw
[47700] 1530630765.611184: FAST armor ccache: FILE:/tmp/krb5cc_testuser
[47700] 1530630765.611208: Retrieving admin@MYREALM ->
krb5_ccache_conf_data/fast_avail/krbtgt\/MYREALM\@MYREALM@X-CACHECONF: from
FILE:/tmp/krb5cc_testuser with result: 0/Success
[47700] 1530630765.611212: Read config in FILE:/tmp/krb5cc_testuser for
krbtgt/MYREALM@MYREALM: fast_avail: yes
[47700] 1530630765.611213: Using FAST due to armor ccache negotiation result
[47700] 1530630765.611219: Getting credentials admin@MYREALM ->
krbtgt/MYREALM@MYREALM using ccache FILE:/tmp/krb5cc_testuser
[47700] 1530630765.611240: Retrieving admin@MYREALM ->
krbtgt/MYREALM@MYREALM from FILE:/tmp/krb5cc_testuser with result: 0/Success
[47700] 1530630765.611245: Armor ccache sesion key: aes256-cts/2559
[47700] 1530630765.611256: Creating authenticator for admin@MYREALM ->
krbtgt/MYREALM@MYREALM, seqnum 0, subkey aes256-cts/2BFD, session key
aes256-cts/2559
[47700] 1530630765.611288: FAST armor key: aes256-cts/62C4
[47700] 1530630765.611299: Encoding request body and padata into FAST
request
[47700] 1530630765.611333: Sending request (1019 bytes) to MYREALM
[47700] 1530630765.611418: Resolving hostname ipamasterhostname
[47700] 1530630765.611608: Initiating TCP connection to stream
ipamasterIP:88
[47700] 1530630765.611769: Sending TCP request to stream ipamasterIP:88
[47700] 1530630765.675154: Received answer from stream ipamasterIP:88
[47700] 1530630765.675208: Response was from master KDC
[47700] 1530630765.675238: Received error from KDC: -1765328359/Additional
pre-authentication required
[47700] 1530630765.675249: Decoding FAST response
[47700] 1530630765.675311: Processing preauth types: 136, 19, 138, 133, 137
[47700] 1530630765.675319: Received cookie: MIT
Password for test_user@MYREALM: 

Here you are asked for a password.


[47700] 1530630765.682884: Preauth module
encrypted_challenge (138) (flags=1) returned: 0/Success
[47700] 1530630765.682889: Produced preauth for next request: 133, 138
[47700] 1530630765.682891: Encoding request body and padata into FAST
request
[47700] 1530630765.682951: Sending request (1118 bytes) to MYREALM
[47700] 1530630765.682967: Resolving hostname ipamasterhostname
[47700] 1530630765.683098: Initiating TCP connection to stream
ipamasterIP:88
[47700] 1530630765.683180: Sending TCP request to stream ipamasterIP:88
[47700] 1530630765.756232: Received answer from stream ipamasterIP:88
[47700] 1530630765.756302: Response was from master KDC
[47700] 1530630765.756321: Received error from KDC:
-1765328360/Preauthentication failed
[47700] 1530630765.756325: Decoding FAST response
[47700] 1530630765.756376: Preauth tryagain input types: 136, 19, 138, 133,
137
kpasswd: Preauthentication failed getting initial ticket

And your password (what kpasswd uses as a password) is incorrect (to
what KDC considers you have as a password).



)
###

I don't understand yet why the commande kpasswd is failing ?

My ticket admin is good.
My ticket cache is used only by me.

May you help me to understand what is going on please ?

Try first to get this working interactively.


Is there a way to use ipa python library to perform a kpasswd 

[Freeipa-users] kpasswd: Preauthentication failed getting initial ticket

[lune voo via FreeIPA-users]

Hello !

I contact you because I encounter a problem when I use kpasswd using python
popen function.
I use freeipa 3.0 and python 2.6.6.

Here is what I do in python :

input_process = otp + '\n' + password + '\n' + password
cmd = 'kpasswd %s' % user_login
cmd_and_args = shlex.split(cmd)
p = Popen(cmd_and_args, stdout=PIPE, stdin=PIPE, stderr=STDOUT)
(output, error) = p.communicate(input=input_process)


Before doing that, I performed the following command in order to have more
logs :
export KRB5_TRACE=/dev/stdout

And here is what I see in the logs :
###
[47700] 1530630765.610794: Getting initial credentials for test_user@MYREALM
[47700] 1530630765.610945: FAST armor ccache: FILE:/tmp/krb5cc_testuser
[47700] 1530630765.610998: Retrieving admin@MYREALM ->
krb5_ccache_conf_data/fast_avail/krbtgt\/MYREALM\@MYREALM@X-CACHECONF: from
FILE:/tmp/krb5cc_testuser with result: 0/Success
[47700] 1530630765.611003: Read config in FILE:/tmp/krb5cc_testuser for
krbtgt/MYREALM@MYREALM: fast_avail: yes
[47700] 1530630765.611006: Using FAST due to armor ccache negotiation result
[47700] 1530630765.611016: Getting credentials admin@MYREALM ->
krbtgt/MYREALM@MYREALM using ccache FILE:/tmp/krb5cc_testuser
[47700] 1530630765.611044: Retrieving admin@MYREALM ->
krbtgt/MYREALM@MYREALM from FILE:/tmp/krb5cc_testuser with result: 0/Success
[47700] 1530630765.611061: Armor ccache sesion key: aes256-cts/2559
[47700] 1530630765.611089: Creating authenticator for admin@MYREALM ->
krbtgt/MYREALM@MYREALM, seqnum 0, subkey aes256-cts/7F39, session key
aes256-cts/2559
[47700] 1530630765.611168: FAST armor key: aes256-cts/79AB
[47700] 1530630765.611179: Setting initial creds service to kadmin/changepw
[47700] 1530630765.611184: FAST armor ccache: FILE:/tmp/krb5cc_testuser
[47700] 1530630765.611208: Retrieving admin@MYREALM ->
krb5_ccache_conf_data/fast_avail/krbtgt\/MYREALM\@MYREALM@X-CACHECONF: from
FILE:/tmp/krb5cc_testuser with result: 0/Success
[47700] 1530630765.611212: Read config in FILE:/tmp/krb5cc_testuser for
krbtgt/MYREALM@MYREALM: fast_avail: yes
[47700] 1530630765.611213: Using FAST due to armor ccache negotiation result
[47700] 1530630765.611219: Getting credentials admin@MYREALM ->
krbtgt/MYREALM@MYREALM using ccache FILE:/tmp/krb5cc_testuser
[47700] 1530630765.611240: Retrieving admin@MYREALM ->
krbtgt/MYREALM@MYREALM from FILE:/tmp/krb5cc_testuser with result: 0/Success
[47700] 1530630765.611245: Armor ccache sesion key: aes256-cts/2559
[47700] 1530630765.611256: Creating authenticator for admin@MYREALM ->
krbtgt/MYREALM@MYREALM, seqnum 0, subkey aes256-cts/2BFD, session key
aes256-cts/2559
[47700] 1530630765.611288: FAST armor key: aes256-cts/62C4
[47700] 1530630765.611299: Encoding request body and padata into FAST
request
[47700] 1530630765.611333: Sending request (1019 bytes) to MYREALM
[47700] 1530630765.611418: Resolving hostname ipamasterhostname
[47700] 1530630765.611608: Initiating TCP connection to stream
ipamasterIP:88
[47700] 1530630765.611769: Sending TCP request to stream ipamasterIP:88
[47700] 1530630765.675154: Received answer from stream ipamasterIP:88
[47700] 1530630765.675208: Response was from master KDC
[47700] 1530630765.675238: Received error from KDC: -1765328359/Additional
pre-authentication required
[47700] 1530630765.675249: Decoding FAST response
[47700] 1530630765.675311: Processing preauth types: 136, 19, 138, 133, 137
[47700] 1530630765.675319: Received cookie: MIT
Password for test_user@MYREALM: [47700] 1530630765.682884: Preauth module
encrypted_challenge (138) (flags=1) returned: 0/Success
[47700] 1530630765.682889: Produced preauth for next request: 133, 138
[47700] 1530630765.682891: Encoding request body and padata into FAST
request
[47700] 1530630765.682951: Sending request (1118 bytes) to MYREALM
[47700] 1530630765.682967: Resolving hostname ipamasterhostname
[47700] 1530630765.683098: Initiating TCP connection to stream
ipamasterIP:88
[47700] 1530630765.683180: Sending TCP request to stream ipamasterIP:88
[47700] 1530630765.756232: Received answer from stream ipamasterIP:88
[47700] 1530630765.756302: Response was from master KDC
[47700] 1530630765.756321: Received error from KDC:
-1765328360/Preauthentication failed
[47700] 1530630765.756325: Decoding FAST response
[47700] 1530630765.756376: Preauth tryagain input types: 136, 19, 138, 133,
137
kpasswd: Preauthentication failed getting initial ticket

)
###

I don't understand yet why the commande kpasswd is failing ?

My ticket admin is good.
My ticket cache is used only by me.

May you help me to understand what is going on please ?
Is there a way to use ipa python library to perform a kpasswd instead of
popen of kpasswd command ?

Best regards.

Lune
___
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://getfedora.org/code-of-conduct.html
List Guidelines: 

[Freeipa-users] Re: AD overwrite not persistence

[Alexander Bokovoy via FreeIPA-users]

On ti, 03 heinä 2018, Michael Gusek via FreeIPA-users wrote:

Ok, i've activated logging for all sections, i'm missed section nss. I
will upload log files next time if i run in trouble.

Please don't post it public as it would contain quite a number of
details about your deployment. 


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/FRPX4P2OHKWFBJQ4FXVCZMMJUV3NAPWB/

[Freeipa-users] Re: admin account getting locked

[Alexander Bokovoy via FreeIPA-users]

On ti, 03 heinä 2018, skrawczenko--- via FreeIPA-users wrote:

Somehow, the admin account is permanently locked

just a simple reproduction

sh-4.2# kinit admin
kinit: Client's credentials have been revoked while getting initial credentials

sh-4.2# kdestroy -A

sh-4.2# kinit 
Password for @bla-bla

sh-4.2# ipa user-unlock admin

Unlocked account "admin"


sh-4.2# kdestroy -A

sh-4.2# kinit admin
Password for admin@bla-bla

sh-4.2# kdestroy -A

sh-4.2# kinit admin
kinit: Client's credentials have been revoked while getting initial credentials

And this is apparently related to the previous issue which still persists
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/message/FY2XZVA5YKB4GYJOABZR3SD6IB7PIL2Z/

Nothing suspicious in the logs or i'm looking at wrong logs.

Any ideas please assist, thanks.

You need to look at /var/log/krb5kdc.log on each master.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/4K34OQLKNJWUBZTNQTMAXGOXVVAE5V6W/

[Freeipa-users] Re: AD overwrite not persistence

[Michael Gusek via FreeIPA-users]

Ok, i've activated logging for all sections, i'm missed section nss. I
will upload log files next time if i run in trouble.

Michael


Am 03.07.2018 um 15:49 schrieb Alexander Bokovoy:
> On ti, 03 heinä 2018, Michael Gusek via FreeIPA-users wrote:
>> Hi Alexander,
>>
>> its SSSD, we check it with id -u u...@example.com.
> Then you need to gather logs from SSSD on IPA master.
> Basically, add
>
> debug_level = 9
>
> in domain and nss sections to /etc/sssd/sssd.conf and restart sssd.
>
> Logs will be large so it would be good to gather them and put somewhere.
>
> General troubleshooting notes apply:
> https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html

-- 




*Michael**Gusek*| System Administrator| Webtrekk GmbH |
*t*+49 30 755 415 302| *f *+49 30 755 415 100 | *w *www.webtrekk.com

Amtsgericht/Local Court Berlin, HRB 93435 B | Geschäftsführer/CEO
Christian Sauer und Norman Wahnschaff


___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/SEGXVFZFOVY2JW7NG5F5CC6MKGCUSRSZ/

[Freeipa-users] admin account getting locked

[skrawczenko--- via FreeIPA-users]

Somehow, the admin account is permanently locked

just a simple reproduction

sh-4.2# kinit admin
kinit: Client's credentials have been revoked while getting initial credentials

sh-4.2# kdestroy -A

sh-4.2# kinit 
Password for @bla-bla

sh-4.2# ipa user-unlock admin

Unlocked account "admin"


sh-4.2# kdestroy -A

sh-4.2# kinit admin
Password for admin@bla-bla

sh-4.2# kdestroy -A

sh-4.2# kinit admin
kinit: Client's credentials have been revoked while getting initial credentials

And this is apparently related to the previous issue which still persists
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/message/FY2XZVA5YKB4GYJOABZR3SD6IB7PIL2Z/

Nothing suspicious in the logs or i'm looking at wrong logs.

Any ideas please assist, thanks.
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/HJHZ4Z6IILSKPMTVUBJ6DGAYRDBWXLFP/

[Freeipa-users] Re: AD overwrite not persistence

[Alexander Bokovoy via FreeIPA-users]

On ti, 03 heinä 2018, Michael Gusek via FreeIPA-users wrote:

Hi Alexander,

its SSSD, we check it with id -u u...@example.com.

Then you need to gather logs from SSSD on IPA master.
Basically, add

debug_level = 9

in domain and nss sections to /etc/sssd/sssd.conf and restart sssd.

Logs will be large so it would be good to gather them and put somewhere.

General troubleshooting notes apply:
https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/XFJTHYJ7KYDRISL53NPZ2MY5DD5AFPEU/

[Freeipa-users] Re: AD overwrite not persistence

[Michael Gusek via FreeIPA-users]

Hi Alexander,

its SSSD, we check it with id -u u...@example.com.

Michael


Am 03.07.2018 um 14:57 schrieb Alexander Bokovoy via FreeIPA-users:
> On ti, 03 heinä 2018, Michael Gusek via FreeIPA-users wrote:
>> Hi,
>>
>> we use an Active Directory (Server 2012) and a FreeIPA 4.5.4
>> installation. FreeIPA runs under Centos 7, sssd version is
>> sssd-1.16.0-19.el7.x86_64. Between AD and FreeIPA we have set up a
>> one-way trust. For some AD users, we have set up a uid override under
>> "Default Trust View" in FreeIPA. This overwrite is regularly lost on the
>> FreeIPA server. If we clear the sssd cache (systemctl stop sssd; rm -rf
>> /var/lib/sss/{db,mc}/*; systemctl start sssd), the override takes effect
>> again. Here is a history for today:
>>
>> 2018-07-03 10:55:01
>> 2018-07-03 11:05:01
>> 2018-07-03 11:06:01
>> 2018-07-03 11:10:01
>> 2018-07-03 11:12:01
>> 2018-07-03 11:15:01
>> 2018-07-03 11:29:01
>> 2018-07-03 11:31:01
>> 2018-07-03 11:34:01
>>
>> As you can see, there is no periodicality, from yesterday to today it
>> runs for about 11h without problems, and today since 11:34
>>
>> How can fix the problem?
> It is unclear from your explanation where is the override lost. Is it
> that LDAP entry for the override disappears? Or is it SSSD that is
> forgetting an override?
>
>



___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/VTWMP4FTUGZWUBWLTHA27OY6ZQTHWISE/

[Freeipa-users] AD overwrite not persistence

[Michael Gusek via FreeIPA-users]

Hi,

we use an Active Directory (Server 2012) and a FreeIPA 4.5.4
installation. FreeIPA runs under Centos 7, sssd version is
sssd-1.16.0-19.el7.x86_64. Between AD and FreeIPA we have set up a
one-way trust. For some AD users, we have set up a uid override under
"Default Trust View" in FreeIPA. This overwrite is regularly lost on the
FreeIPA server. If we clear the sssd cache (systemctl stop sssd; rm -rf
/var/lib/sss/{db,mc}/*; systemctl start sssd), the override takes effect
again. Here is a history for today:

2018-07-03 10:55:01
2018-07-03 11:05:01
2018-07-03 11:06:01
2018-07-03 11:10:01
2018-07-03 11:12:01
2018-07-03 11:15:01
2018-07-03 11:29:01
2018-07-03 11:31:01
2018-07-03 11:34:01

As you can see, there is no periodicality, from yesterday to today it
runs for about 11h without problems, and today since 11:34

How can fix the problem?

Michael



___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/T55Y4KCXR5OIZITBIAWQ3T3PAF36QSQE/