[Freeipa-users] Cannot login to GDM

[Rob Crittenden]

Stephen Gallagher wrote:
> On Fri, 2011-09-23 at 13:38 -0400, Dan Scott wrote:
>> Hi,
>>
>> I've recently upgraded from FreeIPA 1.2 to 2.1. Most things are
>> working OK, but I have a few problems:
>>
>> 1. I'm unable to login to a new client machine via GDM with my
>> existing credentials. i.e. I can login on the command line and my home
>> directory is created correctly, but GDM logins hang, with the fields
>> greyed out until I press escape, when it returns to the login screen.
>> The /var/log/gdm files contain:
>>
>> Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message
>> with a timestamp of 0 for 0x1400007 (Login Wind)
>> Window manager warning: meta_window_activate called by a pager with a
>> 0 timestamp; the pager needs to be fixed.
>> Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message
>> with a timestamp of 0 for 0x1400007 (Login Wind)
>> Window manager warning: meta_window_activate called by a pager with a
>> 0 timestamp; the pager needs to be fixed.
>>
>> ==>  /var/log/gdm/:0-slave.log<==
>> pam: gdm-password[2484]: pam_unix(gdm-password:auth): authentication
>> failure; logname= uid=0 euid=0 tty=:0 ruser= rhost=  user=djscott
>> pam: gdm-password[2484]: pam_sss(gdm-password:auth): authentication
>> success; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=djscott
>>
>> ==>  /var/log/gdm/:0-greeter.log<==
>> Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message
>> with a timestamp of 0 for 0x1400007 (Login Wind)
>> Window manager warning: meta_window_activate called by a pager with a
>> 0 timestamp; the pager needs to be fixed.
>> Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message
>> with a timestamp of 0 for 0x1400007 (Login Wind)
>> Window manager warning: meta_window_activate called by a pager with a
>> 0 timestamp; the pager needs to be fixed.
>> Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message
>> with a timestamp of 0 for 0x1400007 (Login Wind)
>> Window manager warning: meta_window_activate called by a pager with a
>> 0 timestamp; the pager needs to be fixed.
>>
>> Any idea what's going on here?
>
> Could you check /var/log/secure?
>
> Also, what version of the sssd and gdm packages are installed on the
> system?
>
>>
>> 2. I'm having trouble migrating the user passwords. The
>> /ipa/migration/ webpage doesn't work:
>>
>> "There was a problem with your request. Please, try again later."
>>
>> The only way I have been able to migrate user passwords is by getting
>> them to ssh into one of the FreeIPA masters. I've read through
>> manpages for sssd, sssd.conf, sssd-ldap, sssd-krb5 and pam_sss, and
>> the FreeIPA and SSSD websites, but I can't find the documentation for
>> getting SSSD to migrate passwords. Can someone point me in the correct
>> direction?
>>
>
> There's no special configuration required for getting SSSD to migrate
> passwords. As long as password migration mode is configured on the
> FreeIPA server (and SSSD has been set up with ipa-client-install), we
> will detect whether migration mode is active and behave appropriately.
> This is exactly why migration by connecting to the FreeIPA masters by
> SSH works; it's authenticating through the SSSD client on the master and
> performing the migration quietly behind the scenes.
>
> If this isn't working when SSHing into FreeIPA clients other than the
> server, then there's probably something wrong with your SSHD config.
>
> Otherwise, whatever's causing the failure in step 1) is probably causing
> the migration to not work (since authentication isn't completing).
>
>> 3. The migration appears to have created a group for each user, i.e.
>> there is a group called 'djscott' along with my user, visible via an
>> LDAP browser. Should they exist? Is there an easy way to remove them -
>> they don't show up in the web interface or command line, just the LDAP
>> browser.
>
> These are private groups and they are a security feature. The idea is
> that each user is by default a member only of a special group consisting
> only of themselves. This way, when a user creates a file with default
> permissions, it isn't vulnerable to leaking to other members of the
> user's primary group.
>
>> 4. The old ipausers group had ID 1002, which now does not exist,
>> resulting in an annoying "id: cannot find name for group ID 1002"
>> whenever I ssh to another system. Is there a simple way to change the
>> GID for all users who have the old ID to have the new ID? I've created
>> a temporary ipausers-legacy group with ID 1002 to eliminate the error
>> temporarily.
>
> I'll leave this for the core FreeIPA team to discuss, but the removal of
> ipausers was intentional, in favor of using private groups as I
> described above.

There still is an ipausers group, but since it already existed during 
the migration it wasn't migrated, essentially orphaning the old GID. 
I'll open a ticket to consider this.

rob