Description of problem: When adding enterprise login to system, I see error: Failed to register account: No user with the name EXAMPLE\user found Version-Release number of selected component (if applicable): Linux hostname 3.9.9-302.fc19.x86_64 #1 SMP Sat Jul 6 13:41:07 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux How reproducible: Steps to Reproduce: 1. User panel 2. Unlock 3. [+] 4. Enterprise login 5. Domain: example.com, Login name: user, Password: user 6: Add Actual results: Failed to register account: No user with the name EXAMPLE\user found Expected results: Add user to user list. Additional info: Looks like async can't cache my user if I run gnome-control-center -v in terminal: (gnome-control-center:19050): user-accounts-cc-panel-DEBUG: Beginning action, disabling dialog controls (gnome-control-center:19050): user-accounts-cc-panel-DEBUG: Using principal name to kinit: user (gnome-control-center:19050): user-accounts-cc-panel-DEBUG: kinit failed: KDC has no support for encryption type (gnome-control-center:19050): user-accounts-cc-panel-DEBUG: Deleted credential cache: /run/user/1000/um-krb5-creds.SW98ZW (gnome-control-center:19050): user-accounts-cc-panel-DEBUG: Already joined to this realm (gnome-control-center:19050): user-accounts-cc-panel-DEBUG: Permitting login for: EXAMPLE\user * Successfully changed permitted logins for realm (gnome-control-center:19050): user-accounts-cc-panel-DEBUG: Caching remote user: EXAMPLE\user (gnome-control-center:19050): AccountsService-DEBUG: ActUserManager: Caching user (async) 'EXAMPLE\user' user-accounts-cc-panel-Message: Couldn't cache user account: No user with the name EXAMPLE\user found (gnome-control-center:19050): user-accounts-cc-panel-DEBUG: Completed action, enabling dialog controls (gnome-control-center:19050): AccountsService-DEBUG: Ignoring non-user session 13 (class background)
I am having the identical problem. I also followed the steps in https://fedoraproject.org/wiki/QA:Testcase_FreeIPA_control_center without result.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Did you try it with Active Directory or FreeIPA? Could you test it please with already configured FreeIPA demo server? See: http://www.freeipa.org/page/Demo Steps: - Set your hostname: hostname mytestclient.demo1.freeipa.org - Try to add new account: gnome-control-center -v user-accounts > debug.log Domain: demo1.freeipa.org (Domain) Username: admin (Domain) Password: Secret123 If it doesn't work for you, please attach the debug.log.
I tested with the Demo Server and everything worked fine but when i try to connect to my company's Active Directory server i get the error as described on the bug.
I've just configured my AD server and it works correctly for me. Are you testing it with F21? Please try to remove your realm using: realm leave YOURDOMAIN and then try again and provide output of: gnome-control-center -v and output of: realm list
This is taking place on my work pc and i cannot attach any log. i believe this is a server side problem and i do not see the reason to troubleshoot this anymore. Thank you very much for your help.
(In reply to Vasilis Keramidas from comment #6) > This is taking place on my work pc and i cannot attach any log. > i believe this is a server side problem and i do not see the reason to > troubleshoot this anymore. Could you tell me at least, do you see in the logs user in form of: EXAMPLE\user or user@EXAMPLE I wonder, why there is EXAMPLE\user in the attached log, because I have user in form of user@EXAMPLE for FreeIPA and AD also. Maybe this could be a problem for us.
Attaching my log file. I replaced user and domain with USER and DOMAIN Using short domain name -- DOMAIN Joined 'USERPC' to dns domain 'DOMAIN' * LANG=C LOGNAME=root /usr/bin/net -s /var/cache/realmd/realmd-smb-conf.Q39ASX -U USER ads keytab create Enter USER password: * /usr/bin/systemctl enable sssd.service Created symlink from /etc/systemd/system/multi-user.target.wants/sssd.service to /usr/lib/systemd/system/sssd.service. * /usr/bin/systemctl restart sssd.service * /usr/bin/sh -c /usr/sbin/authconfig --update --enablesssd --enablesssdauth --enablemkhomedir --nostart && /usr/bin/systemctl enable oddjobd.service && /usr/bin/systemctl start oddjobd.service * Successfully enrolled machine in realm (gnome-control-center:14055): user-accounts-cc-panel-DEBUG: Completed Join() method call (gnome-control-center:14055): user-accounts-cc-panel-DEBUG: Joining realm completed successfully (gnome-control-center:14055): user-accounts-cc-panel-DEBUG: Permitting login for: USER@DOMAIN * /usr/bin/systemctl restart sssd.service * Successfully changed permitted logins for realm (gnome-control-center:14055): user-accounts-cc-panel-DEBUG: Caching remote user: USER@DOMAIN (gnome-control-center:14055): AccountsService-DEBUG: ActUserManager: Caching user (async) 'USER@DOMAIN' user-accounts-cc-panel-Message: Couldn't cache user account: No user with the name USER@DOMAIN found (gnome-control-center:14055): user-accounts-cc-panel-DEBUG: Completed domain action
Thanks! Will have to look into the caching process, why it fails if realm is configured properly... Changing status back to NEW, because I think we should to investigate why it fails.
The same issue here are. Can't join user to freeipa 4.1 always failing, Also even if I will be able to join GDM login not working. To me is blocker can't enrol new user in organization. Completed enrolment OK Apr 14 14:27:26 pws01 realmd: * Successfully enrolled machine in realm Apr 14 14:27:26 pws01 org.gnome.ControlCenter.SearchProvider: (gnome-control-center:8171): user-accounts-cc-panel-DEBUG: Completed Join() method call Apr 14 14:27:26 pws01 org.gnome.ControlCenter.SearchProvider: (gnome-control-center:8171): user-accounts-cc-panel-DEBUG: Joining realm completed successfully Apr 14 14:27:26 pws01 org.gnome.ControlCenter.SearchProvider: (gnome-control-center:8171): user-accounts-cc-panel-DEBUG: Permitting login for: yuliia Apr 14 14:27:26 pws01 org.gnome.ControlCenter.SearchProvider: * Successfully enrolled machine in realm Apr 14 14:27:26 pws01 realmd: * /usr/bin/systemctl restart sssd.service But then fails Apr 14 14:27:26 pws01 realmd: * Successfully changed permitted logins for realm Apr 14 14:27:26 pws01 org.gnome.ControlCenter.SearchProvider: (gnome-control-center:8171): user-accounts-cc-panel-DEBUG: Caching remote user: yuliia Apr 14 14:27:26 pws01 org.gnome.ControlCenter.SearchProvider: (gnome-control-center:8171): AccountsService-DEBUG: ActUserManager: Caching user (async) 'yuliia' Apr 14 14:27:26 pws01 org.gnome.ControlCenter.SearchProvider: * Successfully changed permitted logins for realm Apr 14 14:27:26 pws01 org.gnome.ControlCenter.SearchProvider: (gnome-control-center:8171): user-accounts-cc-panel-DEBUG: Completed domain action Apr 14 14:27:26 pws01 org.gnome.ControlCenter.SearchProvider: user-accounts-cc-panel-Message: Couldn't cache user account: No user with the name yuliia found
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.