Fedora 30 Client

[Christian Reiss]

Hey folks,

after testing servers, replications et all (all with awesome success) I
am getting to test with clients.

Everything is working except Fedora 30 (Workstation, not Server). I can
do the usual ipa-client-install dance, which will create the kerberos
information. I can get a kerberos ticket using kinit as well as logging
in from a remote host to this one.

However, it is not possible to do a local (gdm) login with valid IPA
account. Neither with "Other User" nor via normal Linux Console (tty*).
sudo denies everything but the local login.

Hint: I am trying to login into the machine that has an existing user
account. Wait, what?

[ 10 Minutes later ]

I created a new user in IPA and logged in from that one. Worked like
magic. So no non-existent users.

So assuming that there might be some users that might have accounts
(read: all  and everyone) -- what's the smartest way to mitigate or migrate?

Thanks!
-Chris.

[Charles Hedrick]

It’s hard to guess without seeing your system:

* pam should be set to check both local password and sssd. If the first fails you need to go on
* /etc/nsswitch.conf should probably put files before sss
* user info in /etc/passwd should be the same as in IPA. If the UID or group is different I could imagine weird effects
> On Jun 29, 2019, at 4:46 PM, Christian Reiss via FreeIPA-users  wrote:
>
> Hey folks,
>
> after testing servers, replications et all (all with awesome success) I
> am getting to test with clients.
>
> Everything is working except Fedora 30 (Workstation, not Server). I can
> do the usual ipa-client-install dance, which will create the kerberos
> information. I can get a kerberos ticket using kinit as well as logging
> in from a remote host to this one.
>
> However, it is not possible to do a local (gdm) login with valid IPA
> account. Neither with "Other User" nor via normal Linux Console (tty*).
> sudo denies everything but the local login.
>
> Hint: I am trying to login into the machine that has an existing user
> account. Wait, what?
>
> [ 10 Minutes later ]
>
> I created a new user in IPA and logged in from that one. Worked like
> magic. So no non-existent users.
>
> So assuming that there might be some users that might have accounts
> (read: all  and everyone) -- what's the smartest way to mitigate or migrate?
>
> Thanks!
> -Chris.
>
> -- 
> Christian Reiss - [e-mail]         /"\  ASCII Ribbon
>                   [e-mail]           \ /    Campaign
>                                                     X   against HTML
> WEB alpha-labs.net                                 / \   in eMails
>
> GPG Retrieval https://gpg.christian-reiss.de
> GPG ID ABCD43C5, 0x44E29126ABCD43C5
> GPG fingerprint = 9549 F537 2596 86BA 733C  A4ED 44E2 9126 ABCD 43C5
>
> "It's better to reign in hell than to serve in heaven.",
>                                          John Milton, Paradise lost.
>
> FreeIPA-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]...

[Christian Reiss]

Spot on.

In my tests I created a VM an in which I also created (by anaconda) my
username with a different uid. On live systems this does not pose an issue.

So, self-created non-issue.

Thanks! :)
-Chris.

On 01/07/2019 15:56, Charles Hedrick wrote:
> It’s hard to guess without seeing your system:
> pam should be set to check both local password and sssd. If the first fails you need to go on
> /etc/nsswitch.conf should probably put files before sss
> user info in /etc/passwd should be the same as in IPA. If the UID or group is different I could imagine weird effects