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

_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to