Re: [Freeipa-users] Default gid for AD trust users

[Lukas Slebodnik]

On (24/08/16 11:42), Orion Poplawski wrote:
>While that is definitely *a* convention, it's not the one we've used which
>puts users by default in shared groups (nwra, visitors, etc).  For example:
>
>uid=2941(user) gid=1991(nwra)
>
The user "user" should be a member "nwra" group.
If no then you have other issues.

Why does it matter whether it is a primary group or no?

LS

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

Re: [Freeipa-users] freeip-4.4.1 on CentOS 7.x ?

[Rob Crittenden]

T.J. Yang wrote:

Hi

I was able to try out freeipa-4.4.1 on fedora 24 server by quick dnf
enable at

https://copr.fedorainfracloud.org/coprs/g/freeipa/freeipa-4-4/

But for production, I am hoping to run 4.4.1 on CentOS 7

Where is the doc explaining on this howto for CentOS 7  ?


It hasn't been released for RHEL/CentOS 7 yet. There is a beta though AFAIU.

rob

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

[Freeipa-users] freeip-4.4.1 on CentOS 7.x ?

[T.J. Yang]

Hi

I was able to try out freeipa-4.4.1 on fedora 24 server by quick dnf enable
at

https://copr.fedorainfracloud.org/coprs/g/freeipa/freeipa-4-4/

But for production, I am hoping to run 4.4.1 on CentOS 7

Where is the doc explaining on this howto for CentOS 7  ?

tj

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

[Freeipa-users] Question about ID views

[Coy Hile]

In looking at the ID Views functionality in FreeIPA, it looks like I can 
accomplish overrides (such as users’ shell in LDAP is /bin/bash, but on a 
certain subset of hosts, users get /some/restrictive/shell instead? (Use case 
#1: a bastion host or jump box where admins might want to validate that users 
are only attempting to access authorized internal destinations.)

However, it looks like one has to list each user individually?

Is it possible to do things like this?
*:/usr/bin/restricted_shell  <— override EVERY user en masse

some_ldap_group:::newGid:::  <—— Override *EVERYONE* in some_ldap_group en masse

ldap_group_2:::newGid::/somepath/home/%s:/usr/bin/restricted_shell
<—— Override members of ldap_group_2 overriding each individual user’s home 
directory as well from, e.g. , /home/jdoe -> /somepath/home/jdoe



--
Coy Hile
coy.h...@coyhile.com


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

Re: [Freeipa-users] Default gid for AD trust users

[Orion Poplawski]

FWIW - I've filed https://fedorahosted.org/freeipa/ticket/6293 to request the
ability to set the primary group for AD trust users.

On 08/24/2016 11:42 AM, Orion Poplawski wrote:
> While that is definitely *a* convention, it's not the one we've used which
> puts users by default in shared groups (nwra, visitors, etc).  For example:
> 
> uid=2941(user) gid=1991(nwra)
> 
> We may be fine changing conventions, but I'm researching whether or not we
> have to.
> 
> Thanks.
> 
> On 08/24/2016 11:19 AM, Justin Stephenson wrote:
>> Could you please explain further what you are trying to accomplish with an AD
>> trust default group? I believe we are following the standard linux convention
>> of creating a user private group using the ID number which matches the uid
>> number for AD trust users.
>>
>> Kind regards,
>>
>> Justin Stephenson
>>
>>
>> On 08/23/2016 06:27 PM, Orion Poplawski wrote:
>>> Is there any way to control the default gid for AD trust users?  At the 
>>> moment
>>> each user has it's own default group, e.g.:
>>>
>>> uid=22603(user@ad.domain) gid=22603(user@ad.domain)
>>>
>>> It would be nice to be able to set this to an actual group.
>>>
>>> Thanks.
>>>
>>
> 
> 


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

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

[Freeipa-users] General query regarding nameserver enrtry

[Deepak Dimri]

Hi All,
My ipa-client-install fails until etc/resolve.conf  gets updated with IPA 
nameserver entry.   I want to avoid a task of updating resolve.conf in my 
automation script.  Is there a way i can get my IPA client installation 
successful without updating resolve.conf? what options do i have?

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

Re: [Freeipa-users] Password change rights

[Alexander Bokovoy]

On Fri, 02 Sep 2016, Rob Crittenden wrote:

Alexander Bokovoy wrote:

On Fri, 02 Sep 2016, Mike Driscoll wrote:

Hello.  I want to script the new user creation process.  I read in
section 9.4 that "any user who has password change rights can change a
password and no password policies are applied, but the other user must
reset the password at the next login.”  I want to create an account
with this limited capability for inclusion in a script.  But I can’t
figure out how to configure an account to have this capability without
being a full admin.  How can I create new user accounts and set initial
passwords in a script?

You need to create a permission that allows to write to password
attributes. Then create a privilege and role that utilize this
permission.

Then you would assign the user that is capable to reset passwords to
that role and it should be enough.

I recently wrote an article how to create new permissions:
https://vda.li/en/posts/2016/08/30/Creating-permissions-in-FreeIPA/

You only need to look at selfservice 'Self can write own
password' and create a normal permission with similar effective
attributes:
# ipa selfservice-show 'Self can write own password'
 Self-service name: Self can write own password
 Permissions: write
 Attributes: userpassword, krbprincipalkey, sambalmpassword,
sambantpassword

Note the difference between selfservice and permission -- the former is
always executed against SELFDN of a bind identity, e.g. those who
authenticate, the latter can take care of both the target and the bind
identity.


There already is such a permission, "System: Change User password"

Thank you, Rob. My bad: we have so many permissions now that default
size limit kicks in and I don't see it:
# ipa permission-find --sizelimit=0 |grep -i 'permission name:'|wc -l
237
# ipa permission-find --sizelimit=0 |grep -i 'permission name:'|grep -i 'change 
user password'
 Permission name: System: Change User password

--
/ Alexander Bokovoy

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

Re: [Freeipa-users] Password change rights

[Rob Crittenden]

Alexander Bokovoy wrote:

On Fri, 02 Sep 2016, Mike Driscoll wrote:

Hello.  I want to script the new user creation process.  I read in
section 9.4 that "any user who has password change rights can change a
password and no password policies are applied, but the other user must
reset the password at the next login.”  I want to create an account
with this limited capability for inclusion in a script.  But I can’t
figure out how to configure an account to have this capability without
being a full admin.  How can I create new user accounts and set initial
passwords in a script?

You need to create a permission that allows to write to password
attributes. Then create a privilege and role that utilize this
permission.

Then you would assign the user that is capable to reset passwords to
that role and it should be enough.

I recently wrote an article how to create new permissions:
https://vda.li/en/posts/2016/08/30/Creating-permissions-in-FreeIPA/

You only need to look at selfservice 'Self can write own
password' and create a normal permission with similar effective
attributes:
# ipa selfservice-show 'Self can write own password'
  Self-service name: Self can write own password
  Permissions: write
  Attributes: userpassword, krbprincipalkey, sambalmpassword,
sambantpassword

Note the difference between selfservice and permission -- the former is
always executed against SELFDN of a bind identity, e.g. those who
authenticate, the latter can take care of both the target and the bind
identity.


There already is such a permission, "System: Change User password"

rob

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

Re: [Freeipa-users] Password change rights

[Alexander Bokovoy]

On Fri, 02 Sep 2016, Mike Driscoll wrote:

Hello.  I want to script the new user creation process.  I read in
section 9.4 that "any user who has password change rights can change a
password and no password policies are applied, but the other user must
reset the password at the next login.”  I want to create an account
with this limited capability for inclusion in a script.  But I can’t
figure out how to configure an account to have this capability without
being a full admin.  How can I create new user accounts and set initial
passwords in a script?

You need to create a permission that allows to write to password
attributes. Then create a privilege and role that utilize this
permission.

Then you would assign the user that is capable to reset passwords to
that role and it should be enough.

I recently wrote an article how to create new permissions:
https://vda.li/en/posts/2016/08/30/Creating-permissions-in-FreeIPA/

You only need to look at selfservice 'Self can write own
password' and create a normal permission with similar effective
attributes:
# ipa selfservice-show 'Self can write own password'
 Self-service name: Self can write own password
 Permissions: write
 Attributes: userpassword, krbprincipalkey, sambalmpassword, sambantpassword

Note the difference between selfservice and permission -- the former is
always executed against SELFDN of a bind identity, e.g. those who
authenticate, the latter can take care of both the target and the bind
identity.
--
/ Alexander Bokovoy

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

[Freeipa-users] Password change rights

[Mike Driscoll]

Hello.  I want to script the new user creation process.  I read in section 9.4 
that "any user who has password change rights can change a password and no 
password policies are applied, but the other user must reset the password at 
the next login.”  I want to create an account with this limited capability for 
inclusion in a script.  But I can’t figure out how to configure an account to 
have this capability without being a full admin.  How can I create new user 
accounts and set initial passwords in a script?

Mike


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

Re: [Freeipa-users] Replication scheme problem

[Mark Reynolds]

On 09/01/2016 06:13 AM, Andrey Rogovsky wrote:
> Hi!
> I have 2 servers - ldap1 is FreeIPA (master) and ldap2 is 389 DS (slave).
> One way replication ldap1 -> ldap2 is enabled but scheme is not
> replicated:
What version of 389-ds-base are you using?

rpm -qa | grep 389-ds-base
>
> Log file ldap1 have this line:
> [01/Sep/2016:07:04:53 +] NSMMReplicationPlugin - Warning: unable
> to replicate schema to host ldap2, port 389. Continuing with total
> update session.
Is there anything in ldap2's errors/access log from this time
(01/Sep/2016:07:04:53)?
>
> There is current status:
> filter: (objectclass=nsds5replicationagreement)
> requesting: All userApplication attributes
> # extended LDIF
> #
> # LDAPv3
> # base 

Re: [Freeipa-users] openLDAP to FreeIPA user migration

[William Muriithi]

Morning Alexander,


>>Failed user:
>>  aagrim: missing attribute "sn" required by object class 
>> "organizationalPerson"
>>  acctemp: missing attribute "sn" required by object class
>>"organizationalPerson"
>> ...
> This looks like a common problem. I had recently made a small 'hack' to
> solve this problem.
>
> Following small fixup plugin could be used to affect how entries are
> generated. If you add it to /usr/lib/python2.7/site-packages/ipalib/plugins
> on IPA master and restart httpd service, the plugin would modify migrate-ds 
> command so
> that 'sn' attribute would be set to a 'Migrated User Last Name' for all
> entries that miss 'sn' attribute before they actually get added into IPA
> LDAP.
>
> This is an experimental hack, of course, but it should work. Once
> migration is finished, don't forget to remove the file and restart httpd
> service again.

Worked for me, thank you.  Curious, would this qualify for inclusion
in future IPA release considering its a common problem that show up
often?

>
Regards,

William

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

Re: [Freeipa-users] openLDAP to FreeIPA user migration

[Alexander Bokovoy]

On Fri, 02 Sep 2016, Ernedin Zajko wrote:

Hi Alexander,

thank you for this  - i think this should even work for missing some
mandatory (gid) attributes...

Yes, this fixup module can be used for anything to inject.



regards,

--- Ernedin ZAJKO
eza...@root.ba


340282366920938463463374607431768211456




On Thu, Sep 1, 2016 at 9:26 PM, Alexander Bokovoy  wrote:

On Thu, 01 Sep 2016, William Muriithi wrote:


Afternoon,

I have an openLDAP system that lack a required attribute.  This result
in the migration script rejecting all the user import.

I have googled externsively, read ever line of ipa migration --help
doc and it doesn't seem I will be able to use this migration script.
I wonder if there is anybody here who have been able to overcome this
problem in the past.

[root@hydrogen ~]# ipa -v migrate-ds --with-compat
--bind-dn="cn=admin,dc=eng.example,dc=com"
--user-ignore-attribute="sn"
--user-container="ou=People,dc=eng.example,dc=com"
--group-container="ou=Group,dc=eng.example,dc=com"
--group-objectclass="posixGroup"   --user-objectclass="account"
ldap://192.168.20.18:389
ipa: INFO: trying https://hydrogen.eng.example.com/ipa/session/json
Password:
ipa: INFO: Forwarding 'migrate_ds' to json server
'https://hydrogen.eng.example.com/ipa/session/json'
---
migrate-ds:
---
Migrated:
Failed user:
 aagrim: missing attribute "sn" required by object class
"organizationalPerson"
 acctemp: missing attribute "sn" required by object class
"organizationalPerson"
...


This looks like a common problem. I had recently made a small 'hack' to
solve this problem.

Following small fixup plugin could be used to affect how entries are
generated. If you add it to /usr/lib/python2.7/site-packages/ipalib/plugins
on IPA master and restart httpd service, the plugin would modify migrate-ds
command so
that 'sn' attribute would be set to a 'Migrated User Last Name' for all
entries that miss 'sn' attribute before they actually get added into IPA
LDAP.

This is an experimental hack, of course, but it should work. Once
migration is finished, don't forget to remove the file and restart httpd
service again.

--
/ Alexander Bokovoy

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


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


--
/ Alexander Bokovoy

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

Re: [Freeipa-users] openLDAP to FreeIPA user migration

[Ernedin Zajko]

Hi Alexander,

thank you for this  - i think this should even work for missing some
mandatory (gid) attributes...

regards,

--- Ernedin ZAJKO
 eza...@root.ba

> 340282366920938463463374607431768211456



On Thu, Sep 1, 2016 at 9:26 PM, Alexander Bokovoy  wrote:
> On Thu, 01 Sep 2016, William Muriithi wrote:
>>
>> Afternoon,
>>
>> I have an openLDAP system that lack a required attribute.  This result
>> in the migration script rejecting all the user import.
>>
>> I have googled externsively, read ever line of ipa migration --help
>> doc and it doesn't seem I will be able to use this migration script.
>> I wonder if there is anybody here who have been able to overcome this
>> problem in the past.
>>
>> [root@hydrogen ~]# ipa -v migrate-ds --with-compat
>> --bind-dn="cn=admin,dc=eng.example,dc=com"
>> --user-ignore-attribute="sn"
>> --user-container="ou=People,dc=eng.example,dc=com"
>> --group-container="ou=Group,dc=eng.example,dc=com"
>> --group-objectclass="posixGroup"   --user-objectclass="account"
>> ldap://192.168.20.18:389
>> ipa: INFO: trying https://hydrogen.eng.example.com/ipa/session/json
>> Password:
>> ipa: INFO: Forwarding 'migrate_ds' to json server
>> 'https://hydrogen.eng.example.com/ipa/session/json'
>> ---
>> migrate-ds:
>> ---
>> Migrated:
>> Failed user:
>>  aagrim: missing attribute "sn" required by object class
>> "organizationalPerson"
>>  acctemp: missing attribute "sn" required by object class
>> "organizationalPerson"
>> ...
>
> This looks like a common problem. I had recently made a small 'hack' to
> solve this problem.
>
> Following small fixup plugin could be used to affect how entries are
> generated. If you add it to /usr/lib/python2.7/site-packages/ipalib/plugins
> on IPA master and restart httpd service, the plugin would modify migrate-ds
> command so
> that 'sn' attribute would be set to a 'Migrated User Last Name' for all
> entries that miss 'sn' attribute before they actually get added into IPA
> LDAP.
>
> This is an experimental hack, of course, but it should work. Once
> migration is finished, don't forget to remove the file and restart httpd
> service again.
>
> --
> / Alexander Bokovoy
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

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

Re: [Freeipa-users] Migrate users with password from one IPA to another

[Rene Trippen]

Hi,

is it possible to transfer the Kerberos Master Key to the new IPA Server?

- rene

On 31.08.2016 10:57, Rene Trippen wrote:

On 25.08.2016 19:44, Rob Crittenden wrote:

Rene Trippen wrote:

Hi,

I`ve got an IPA with a broken CA infrastructure (don`t know what
happened, but new clients cannot be registered)
It is even not possible to setup a new replica.


It may be fairly straightforward to getting the CA back up. How is it
broken?

I don't know how that happened exactly, we had an IPA 3.x Server, then 
we migrated it to another machine and upgraded to IPA 4.1, later, we 
upgraded (on the same machine) to IPA 4.2.
The IPA Server is basically working, but when I want to register a new 
machine, the registration process fails with following (I think these 
are the relevant lines) error


2016-08-30T22:40:25Z DEBUG flushing ldap://ipa.internal.domain:389 
from SchemaCache
2016-08-30T22:40:25Z DEBUG retrieving schema for SchemaCache 
url=ldap://ipa.internal.domain:389 
conn=
2016-08-30T22:40:26Z DEBUG Adding CA certificates to the IPA NSS 
database.

2016-08-30T22:40:26Z DEBUG Starting external process
2016-08-30T22:40:26Z DEBUG args='/usr/bin/certutil' '-d' 
'/etc/ipa/nssdb' '-A' '-n' 'INTERNAL.DOMAIN IPA CA' '-t' 'CT,C,C'

2016-08-30T22:40:26Z DEBUG Process finished, return code=0
2016-08-30T22:40:26Z DEBUG stdout=
2016-08-30T22:40:26Z DEBUG stderr=
2016-08-30T22:40:26Z DEBUG Starting external process
2016-08-30T22:40:26Z DEBUG args='/usr/bin/certutil' '-d' 
'/etc/ipa/nssdb' '-A' '-n' 'INTERNAL.DOMAIN IPA CA' '-t' 'CT,C,C'

2016-08-30T22:40:26Z DEBUG Process finished, return code=255
2016-08-30T22:40:26Z DEBUG stdout=
2016-08-30T22:40:26Z DEBUG stderr=certutil: could not add certificate 
to token or database: SEC_ERROR_ADDING_CERT: Error adding certificate 
to database.


2016-08-30T22:40:26Z ERROR Failed to add INTERNAL.DOMAIN IPA CA to the 
IPA NSS database.

2016-08-30T22:40:26Z ERROR Installation failed. Rolling back changes.


The client tries to add 2 certificates, but fails with the second, I 
think, it is because we have 2 CA certificates (one from the old IPA 
3.x server and one from the new 4.x server). My current workaround is 
to register the client with an ipa3.x client, then I do an upgrade to 
the 4.x client


I've tried many ways to setup a new CA:
- tried ipa-cacert-manage renew
- tried to setup a new replica with new CA, but the setup failed with 
the same problems described above
- tried to remove all old certificates refering to the old ipa server 
(but I think I failed somewhere)


My thoughts are, the CA is in a bad condition, and I spent much time 
in trying to fix it, with no success. And, my fears are, if I find 
some crude, not documented workaround for the CA problem, the problem 
maybe pops up at the next update. So, setting up a fresh IPA and 
migrating everything (except the clients), was my hope to get an IPA 
running without all the CA problems. Migrating the clients is not the 
problem, that can be done by script (spacewalk or ansible), but 
migrating the users is not that easy, because the users cannot be 
scripted :)




So, I wanted to setup a new IPA Server with new CA, and I want to move
all users with their passwords to the new IPA instance.
I`ve tried with 'ipa migrate-ds'

ipa migrate-ds --continue --bind-dn="cn=Directory Manager"
--user-container=cn=users,cn=accounts
--group-container=cn=groups,cn=accounts --group-objectclass=posixgroup
--group-overwrite-gid --with-compat ldap://

The output is OK
===
Passwords have been migrated in pre-hashed format.
IPA is unable to generate Kerberos keys unless provided
with clear text passwords. All migrated users need to
login at https://your.domain/ipa/migration/ before they
can use their Kerberos accounts.


But  the ipa/migration website is not working for me.
Anyway, is there a way to export the users with passwords? I think I
have to export some kerberos specific stuff from the old IPA?


The log file /var/log/httpd/error_log may have details on what isn't
working.


Sorry, that was not clearly described:

The site is basically working, but when I enter the password, nothing 
happens in the backend (I cannot login with my user on the ipa login 
site).


- rene



The way to export users with passwords is the method you've already
tried. To not have to change a password at all would require the same
Kerberos master key and these are generated randomly at install time.

rob





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

Re: [Freeipa-users] SUDO and group lookup in AD trust

[Jakub Hrozek]

On Fri, Sep 02, 2016 at 09:27:57AM +0200, Lukas Slebodnik wrote:
> On (26/08/16 07:54), Jakub Hrozek wrote:
> >On Thu, Aug 25, 2016 at 10:41:53PM +0200, Lukas Slebodnik wrote:
> >> On (25/08/16 11:30), Troels Hansen wrote:
> >> >Hmm, adding the CentOS SSSD 1.14 copr repo and running yum upgrade,
> >> >getting a version 1.14.1, clean cache DB (complaing about cache being
> >> >old version),
> >> Upgrade to 1.14.1 should not require puring sssd cache.
> >> If you are able to reproduce then please provide steps.
> >> Or file a sssd bug https://fedorahosted.org/sssd/newticket
> >> 
> >> >I can getent users, but log log in for no obvious reason (system error in 
> >> >secure.log).
> >> >
> >> system error sounds bad. Please provide log files with
> >> high debug level in domain section sssd.conf
> >> 
> >> https://fedorahosted.org/sssd/wiki/Troubleshooting#SSSDdebuglogs
> >
> >We were debugging this yesterday with Troels and the logs said it's:
> >https://fedorahosted.org/sssd/ticket/3127
> >
> Fixed version is in 1.14 copr

Thank you, btw another affected user confirmed that the patch fixes the
problem.

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

Re: [Freeipa-users] SUDO and group lookup in AD trust

[Lukas Slebodnik]

On (26/08/16 07:54), Jakub Hrozek wrote:
>On Thu, Aug 25, 2016 at 10:41:53PM +0200, Lukas Slebodnik wrote:
>> On (25/08/16 11:30), Troels Hansen wrote:
>> >Hmm, adding the CentOS SSSD 1.14 copr repo and running yum upgrade,
>> >getting a version 1.14.1, clean cache DB (complaing about cache being
>> >old version),
>> Upgrade to 1.14.1 should not require puring sssd cache.
>> If you are able to reproduce then please provide steps.
>> Or file a sssd bug https://fedorahosted.org/sssd/newticket
>> 
>> >I can getent users, but log log in for no obvious reason (system error in 
>> >secure.log).
>> >
>> system error sounds bad. Please provide log files with
>> high debug level in domain section sssd.conf
>> 
>> https://fedorahosted.org/sssd/wiki/Troubleshooting#SSSDdebuglogs
>
>We were debugging this yesterday with Troels and the logs said it's:
>https://fedorahosted.org/sssd/ticket/3127
>
Fixed version is in 1.14 copr

LS

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