Hi, I try sssd-1.9.2 on Ubuntu-Quantal with ad-provider.
So far I can login to the desktop with AD identity; Login hangs a bit because of unknown group;
What is the best practice to resolve the group (set up PrimaryGroupId, run idmap????)
The option 'default_shell = /bin/bash' in sssd.conf doesn't seem to have effect. I would expect it being visible In users info:
getent passwd imadatestuser imadatestuser:*:332410389:332400513:IMADAtest Testesen:/home/imadatestuser:
In pam.d/common-session I added entry for case of nonexistent homedir reference, and shell - so ADuser can login.
There is a lot of messages in sssd_nat.c.sdu.dk - for searching principal info for lightdm in AD - Is it correct? Shouldn't be sssd awared that lightdm is a local service?
..................... Tue Nov 13 10:29:29 2012) [sssd[be[nat.c.sdu.dk]]] [sbus_message_handler] (0x4000): Received SBUS method [pamHandler] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [be_pam_handler] (0x0100): Got request with the following data (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [pam_print_data] (0x0100): command: PAM_OPEN_SESSION (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [pam_print_data] (0x0100): domain: nat.c.sdu.dk (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [pam_print_data] (0x0100): user: imadatestuser (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [pam_print_data] (0x0100): service: lightdm ^^^^^^^^
(Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [pam_print_data] (0x0100): tty: :0 (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [pam_print_data] (0x0100): ruser: (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [pam_print_data] (0x0100): rhost: (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [pam_print_data] (0x0100): authtok type: 0 (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [pam_print_data] (0x0100): authtok size: 0 (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [pam_print_data] (0x0100): newauthtok type: 0 (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [pam_print_data] (0x0100): newauthtok size: 0 (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [pam_print_data] (0x0100): priv: 1 (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [pam_print_data] (0x0100): cli_pid: 2564 (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [be_pam_handler] (0x0100): Sending result [0][nat.c.sdu.dk] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sbus_dispatch] (0x4000): dbus conn: 7063D0 (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sbus_message_handler] (0x4000): Received SBUS method [getDomains] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [be_get_subdomains] (0x2000): Undefined backend target. (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sbus_dispatch] (0x4000): dbus conn: 7063D0 (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [be_get_account_info] (0x0100): Got request for [4099][1][name=lightdm] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_initgr_send] (0x4000): Retrieving info for initgroups call (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_initgr_next_base] (0x0400): Searching for users with base [ou=ADUsers,dc=nat,dc=c,dc=sdu,dc=dk] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(sAMAccountName=lightdm)(objectclass=person))][ou=ADUsers,dc=nat,dc=c,dc=sdu,dc=dk].^
^^^^^^^^^^^^^^ (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sAMAccountName] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [unixUserPassword] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uidNumber] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gecos] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [unixHomeDirectory] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginShell] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPrincipalName] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [name] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectGUID] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectSID] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [primaryGroupID] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [whenChanged] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uSNChanged] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [accountExpires] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userAccountControl] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 13 (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_process_result] (0x2000): Trace: sh[0x6e8e00], connected[1], ops[0x76c190], ldap[0x713300] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_initgr_user] (0x4000): Receiving info for the user (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_id_op_done] (0x4000): releasing operation connection (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x7555e0 (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [ldb] (0x4000): tevent: Destroying timer event 0x6f8740 "ltdb_timeout"
(Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [ldb] (0x4000): tevent: Ending timer event 0x6f4c60 "ltdb_callback"
(Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sysdb_search_groups] (0x2000): No such entry (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sysdb_delete_user] (0x0400): Error: 2 (No such file or directory) (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_process_result] (0x2000): Trace: sh[0x6e8e00], connected[1], ops[(nil)], ldap[0x713300] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sbus_dispatch] (0x4000): dbus conn: 707F80 (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [be_get_account_info] (0x0100): Got request for [3][1][name=lightdm]
^^^^^^^^ (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_initgr_send] (0x4000): Retrieving info for initgroups call (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_initgr_next_base] (0x0400): Searching for users with base [ou=ADUsers,dc=nat,dc=c,dc=sdu,dc=dk] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(sAMAccountName=lightdm)(objectclass=person))][ou=ADUsers,dc=nat,dc=c,dc=sdu,dc=dk]. ......
I can also see a lot of messages:
... (Tue Nov 13 13:10:33 2012) [sssd[be[nat.c.sdu.dk]]] [sbus_message_handler] (0x4000): Received SBUS method [getDomains] (Tue Nov 13 13:10:33 2012) [sssd[be[nat.c.sdu.dk]]] [be_get_subdomains] (0x2000): Undefined backend target. (Tue Nov 13 13:10:33 2012) [sssd[be[nat.c.sdu.dk]]] [sbus_dispatch] (0x4000): dbus conn: EA75B0 (Tue Nov 13 13:10:33 2012) [sssd[be[nat.c.sdu.dk]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Nov 13 13:10:33 2012) [sssd[be[nat.c.sdu.dk]]] [sbus_message_handler] (0x4000): Received SBUS method [getDomains] (Tue Nov 13 13:10:33 2012) [sssd[be[nat.c.sdu.dk]]] [be_get_subdomains] (0x2000): Undefined backend target. ... Do I miss specific parameter in sssd.conf?
Thanks in advance
longina
On Tue, Nov 13, 2012 at 12:44:45PM +0000, Longina Przybyszewska wrote:
Hi, I try sssd-1.9.2 on Ubuntu-Quantal with ad-provider.
So far I can login to the desktop with AD identity; Login hangs a bit because of unknown group;
What is the best practice to resolve the group (set up PrimaryGroupId, run idmap????)
Sorry, I don't quite understand this problem...are you seeing a particular group GID not being converted from SID?
Or are you seeing failures due to the SSSD attempting to convert any of the "local" groups such as "Domain Users" ?
The option 'default_shell = /bin/bash' in sssd.conf doesn't seem to have effect. I would expect it being visible In users info:
Into which section in the SSSD did you put the default_shell option? In 1.9.2 it was only supported in the [nss] section, we changed the option to also take effect in the domain section during 1.9.3 development.
getent passwd imadatestuser imadatestuser:*:332410389:332400513:IMADAtest Testesen:/home/imadatestuser:
In pam.d/common-session I added entry for case of nonexistent homedir reference, and shell - so ADuser can login.
Do your users have any home directory at all? Could you maybe use the fallback_homedir or override_homedir directives?
There is a lot of messages in sssd_nat.c.sdu.dk - for searching principal info for lightdm in AD - Is it correct? Shouldn't be sssd awared that lightdm is a local service?
..................... Tue Nov 13 10:29:29 2012) [sssd[be[nat.c.sdu.dk]]] [sbus_message_handler] (0x4000): Received SBUS method [pamHandler] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [be_pam_handler] (0x0100): Got request with the following data (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [pam_print_data] (0x0100): command: PAM_OPEN_SESSION (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [pam_print_data] (0x0100): domain: nat.c.sdu.dk (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [pam_print_data] (0x0100): user: imadatestuser (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [pam_print_data] (0x0100): service: lightdm ^^^^^^^^
This is OK, I guess that lightdm is your display manager and there would be a file such as /etc/pam.d/lightdm on your system? These messages are just telling that a PAM session was opened for a user who was logging in wusing the lightdm service.
(Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [pam_print_data] (0x0100): tty: :0 (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [pam_print_data] (0x0100): ruser: (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [pam_print_data] (0x0100): rhost: (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [pam_print_data] (0x0100): authtok type: 0 (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [pam_print_data] (0x0100): authtok size: 0 (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [pam_print_data] (0x0100): newauthtok type: 0 (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [pam_print_data] (0x0100): newauthtok size: 0 (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [pam_print_data] (0x0100): priv: 1 (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [pam_print_data] (0x0100): cli_pid: 2564 (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [be_pam_handler] (0x0100): Sending result [0][nat.c.sdu.dk] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sbus_dispatch] (0x4000): dbus conn: 7063D0 (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sbus_message_handler] (0x4000): Received SBUS method [getDomains] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [be_get_subdomains] (0x2000): Undefined backend target. (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sbus_dispatch] (0x4000): dbus conn: 7063D0 (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [be_get_account_info] (0x0100): Got request for [4099][1][name=lightdm] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_initgr_send] (0x4000): Retrieving info for initgroups call (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_initgr_next_base] (0x0400): Searching for users with base [ou=ADUsers,dc=nat,dc=c,dc=sdu,dc=dk] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(sAMAccountName=lightdm)(objectclass=person))][ou=ADUsers,dc=nat,dc=c,dc=sdu,dc=dk].^
^^^^^^^^^^^^^^
This looks like some application called getpwnam("lightdm"). You can "blacklist" users that are known to be local using the filter_users and filter_groups options.
(Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sAMAccountName] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [unixUserPassword] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uidNumber] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gecos] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [unixHomeDirectory] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginShell] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPrincipalName] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [name] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectGUID] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectSID] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [primaryGroupID] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [whenChanged] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uSNChanged] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [accountExpires] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userAccountControl] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 13 (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_process_result] (0x2000): Trace: sh[0x6e8e00], connected[1], ops[0x76c190], ldap[0x713300] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_initgr_user] (0x4000): Receiving info for the user (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_id_op_done] (0x4000): releasing operation connection (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x7555e0 (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [ldb] (0x4000): tevent: Destroying timer event 0x6f8740 "ltdb_timeout"
(Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [ldb] (0x4000): tevent: Ending timer event 0x6f4c60 "ltdb_callback"
(Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sysdb_search_groups] (0x2000): No such entry (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sysdb_delete_user] (0x0400): Error: 2 (No such file or directory) (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_process_result] (0x2000): Trace: sh[0x6e8e00], connected[1], ops[(nil)], ldap[0x713300] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sbus_dispatch] (0x4000): dbus conn: 707F80 (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [be_get_account_info] (0x0100): Got request for [3][1][name=lightdm]
^^^^^^^^(Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_initgr_send] (0x4000): Retrieving info for initgroups call (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_initgr_next_base] (0x0400): Searching for users with base [ou=ADUsers,dc=nat,dc=c,dc=sdu,dc=dk] (Tue Nov 13 10:29:30 2012) [sssd[be[nat.c.sdu.dk]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(sAMAccountName=lightdm)(objectclass=person))][ou=ADUsers,dc=nat,dc=c,dc=sdu,dc=dk]. ......
I can also see a lot of messages:
... (Tue Nov 13 13:10:33 2012) [sssd[be[nat.c.sdu.dk]]] [sbus_message_handler] (0x4000): Received SBUS method [getDomains] (Tue Nov 13 13:10:33 2012) [sssd[be[nat.c.sdu.dk]]] [be_get_subdomains] (0x2000): Undefined backend target. (Tue Nov 13 13:10:33 2012) [sssd[be[nat.c.sdu.dk]]] [sbus_dispatch] (0x4000): dbus conn: EA75B0 (Tue Nov 13 13:10:33 2012) [sssd[be[nat.c.sdu.dk]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Nov 13 13:10:33 2012) [sssd[be[nat.c.sdu.dk]]] [sbus_message_handler] (0x4000): Received SBUS method [getDomains] (Tue Nov 13 13:10:33 2012) [sssd[be[nat.c.sdu.dk]]] [be_get_subdomains] (0x2000): Undefined backend target.
I think these confusing DEBUG messages have been fixed in 1.9.3 as well.
-----Original Message----- From: sssd-users-bounces@lists.fedorahosted.org [mailto:sssd-users-bounces@lists.fedorahosted.org] On Behalf Of Jakub Hrozek Sent: 13. november 2012 14:58 To: sssd-users@lists.fedorahosted.org Subject: Re: [SSSD-users] problems sssd-1.9.2
On Tue, Nov 13, 2012 at 12:44:45PM +0000, Longina Przybyszewska wrote:
Hi, I try sssd-1.9.2 on Ubuntu-Quantal with ad-provider.
So far I can login to the desktop with AD identity; Login hangs a bit because of unknown group;
What is the best practice to resolve the group (set up PrimaryGroupId, run idmap????)
Sorry, I don't quite understand this problem...are you seeing a particular group GID not being converted from SID?
Or are you seeing failures due to the SSSD attempting to convert any of the "local" groups such as "Domain Users" ?
I see messages about groups - why so many at one aduser login? .......... Groups: cannot find name for group ID 332400513 Groups: cannot find name for group ID 988022561 Groups: cannot find name for group ID 988803222 Groups: cannot find name for group ID ..... ....and tens more...
The option 'default_shell = /bin/bash' in sssd.conf doesn't seem to have effect. I would expect it being visible In users info:
Into which section in the SSSD did you put the default_shell option? In 1.9.2 it was only supported in the [nss] section, we changed the option to also take effect in the domain section during 1.9.3 development.
OK - I put it into [domain]
getent passwd imadatestuser imadatestuser:*:332410389:332400513:IMADAtest Testesen:/home/imadatestuser:
In pam.d/common-session I added entry for case of nonexistent homedir reference, and shell - so ADuser can login.
Do your users have any home directory at all? Could you maybe use the fallback_homedir or override_homedir directives?
Yes, I do use fallback_homedir in [domain] section and that works.
Linux users have homedirs on NFSserver - auto.home maps are in NIS format.
Your SSSD is really great piece of software - so elegant concept ! I love it.
Best longina
_______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Tue, Nov 13, 2012 at 03:40:14PM +0000, Longina Przybyszewska wrote:
-----Original Message----- From: sssd-users-bounces@lists.fedorahosted.org [mailto:sssd-users-bounces@lists.fedorahosted.org] On Behalf Of Jakub Hrozek Sent: 13. november 2012 14:58 To: sssd-users@lists.fedorahosted.org Subject: Re: [SSSD-users] problems sssd-1.9.2
On Tue, Nov 13, 2012 at 12:44:45PM +0000, Longina Przybyszewska wrote:
Hi, I try sssd-1.9.2 on Ubuntu-Quantal with ad-provider.
So far I can login to the desktop with AD identity; Login hangs a bit because of unknown group;
What is the best practice to resolve the group (set up PrimaryGroupId, run idmap????)
Sorry, I don't quite understand this problem...are you seeing a particular group GID not being converted from SID?
Or are you seeing failures due to the SSSD attempting to convert any of the "local" groups such as "Domain Users" ?
I see messages about groups - why so many at one aduser login? .......... Groups: cannot find name for group ID 332400513 Groups: cannot find name for group ID 988022561 Groups: cannot find name for group ID 988803222 Groups: cannot find name for group ID ..... ....and tens more...
OK, I suspect you are hitting https://bugzilla.redhat.com/show_bug.cgi?id=867874 which was resolved recently as well.
The option 'default_shell = /bin/bash' in sssd.conf doesn't seem to have effect. I would expect it being visible In users info:
Into which section in the SSSD did you put the default_shell option? In 1.9.2 it was only supported in the [nss] section, we changed the option to also take effect in the domain section during 1.9.3 development.
OK - I put it into [domain]
Right, in 1.9.2 it only works in the [nss] section. It's going to also work from the [domain] section in 1.9.3
getent passwd imadatestuser imadatestuser:*:332410389:332400513:IMADAtest Testesen:/home/imadatestuser:
In pam.d/common-session I added entry for case of nonexistent homedir reference, and shell - so ADuser can login.
Do your users have any home directory at all? Could you maybe use the fallback_homedir or override_homedir directives?
Yes, I do use fallback_homedir in [domain] section and that works.
Linux users have homedirs on NFSserver - auto.home maps are in NIS format.
You might also be interested in the automounter integration, although I'm not sure that piece of functionality had been backported to Ubuntu yet. The Ubuntu automounter maintainer would know best.
Your SSSD is really great piece of software - so elegant concept ! I love it.
We are really glad to hear this, thank you!
-----Original Message----- From: sssd-users-bounces@lists.fedorahosted.org [mailto:sssd-users-bounces@lists.fedorahosted.org] On Behalf Of Jakub Hrozek Sent: 13. november 2012 17:38 To: sssd-users@lists.fedorahosted.org Subject: Re: [SSSD-users] problems sssd-1.9.2
On Tue, Nov 13, 2012 at 03:40:14PM +0000, Longina Przybyszewska wrote:
-----Original Message----- From: sssd-users-bounces@lists.fedorahosted.org [mailto:sssd-users-bounces@lists.fedorahosted.org] On Behalf Of Jakub Hrozek Sent: 13. november 2012 14:58 To: sssd-users@lists.fedorahosted.org Subject: Re: [SSSD-users] problems sssd-1.9.2
On Tue, Nov 13, 2012 at 12:44:45PM +0000, Longina Przybyszewska wrote:
Hi, I try sssd-1.9.2 on Ubuntu-Quantal with ad-provider.
You might also be interested in the automounter integration, although I'm not sure that piece of functionality had been backported to Ubuntu yet. The Ubuntu automounter maintainer would know best.
Oh, yes - how stable is automounter integration in the latest stable SSSD? Is I enough to use autofs-5 - or does it need more integration with some SSSD moduls/libraries?
Until I am lucky to get new packages from Ubuntu maintainers - can I use nsswitch pointing to auto.home maps - would it work with SSSD?
Best regards longina
Your SSSD is really great piece of software - so elegant concept ! I love it.
We are really glad to hear this, thank you! _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Thu, Nov 15, 2012 at 09:43:39AM +0000, Longina Przybyszewska wrote:
-----Original Message----- From: sssd-users-bounces@lists.fedorahosted.org [mailto:sssd-users-bounces@lists.fedorahosted.org] On Behalf Of Jakub Hrozek Sent: 13. november 2012 17:38 To: sssd-users@lists.fedorahosted.org Subject: Re: [SSSD-users] problems sssd-1.9.2
On Tue, Nov 13, 2012 at 03:40:14PM +0000, Longina Przybyszewska wrote:
-----Original Message----- From: sssd-users-bounces@lists.fedorahosted.org [mailto:sssd-users-bounces@lists.fedorahosted.org] On Behalf Of Jakub Hrozek Sent: 13. november 2012 14:58 To: sssd-users@lists.fedorahosted.org Subject: Re: [SSSD-users] problems sssd-1.9.2
On Tue, Nov 13, 2012 at 12:44:45PM +0000, Longina Przybyszewska wrote:
Hi, I try sssd-1.9.2 on Ubuntu-Quantal with ad-provider.
You might also be interested in the automounter integration, although I'm not sure that piece of functionality had been backported to Ubuntu yet. The Ubuntu automounter maintainer would know best.
Oh, yes - how stable is automounter integration in the latest stable SSSD? Is I enough to use autofs-5 - or does it need more integration with some SSSD moduls/libraries?
I think the sss support was introduced in autofs 5.0.6, at least in Fedora. I'm actually not quite sure about autofs upstream. You need to look for the lookup_sss.so module.
Until I am lucky to get new packages from Ubuntu maintainers - can I use nsswitch pointing to auto.home maps - would it work with SSSD?
The SSSD integration is provided by the lookup_sss.so module, which is able to talk to the autofs responder process of the SSSD. If your distribution doesn't provide that module, you should still be able to fall back to the LDAP lookups. You just won't be able to leverage the unified configuration in sssd.conf and caching of the maps.
Thanks. I get it finally working!! : Ubuntu-Quantal sssd+ad_provider+NFSv4 - :-)) but still have some issues: 1. Ticket expires after 10 hours - I run msktutil (application for joining linux to AD and adding principals to the account and some more) daily in crontab to prevent ticket expiration - maybe this is not necessary? Anyway, I ends having to manually reset machine's account and create a new keytab ( it is inefficient, but haven't figured out yet another way) How does sssd renew tickets if machine was offline more then 10 hours?
2. To get rid off listing of tens of group at login, I use the option:
ldap_group_member = uniqueMember
It works during login (no more long list, and login delay), but doesn't work when changing personality with 'su -' (again long list of numbers+ login delay)
Best regards Longina
-----Original Message----- From: sssd-users-bounces@lists.fedorahosted.org [mailto:sssd-users-bounces@lists.fedorahosted.org] On Behalf Of Jakub Hrozek Sent: 22. november 2012 17:55 To: sssd-users@lists.fedorahosted.org Subject: Re: [SSSD-users] problems sssd-1.9.2
On Thu, Nov 15, 2012 at 09:43:39AM +0000, Longina Przybyszewska wrote:
-----Original Message----- From: sssd-users-bounces@lists.fedorahosted.org [mailto:sssd-users-bounces@lists.fedorahosted.org] On Behalf Of Jakub Hrozek Sent: 13. november 2012 17:38 To: sssd-users@lists.fedorahosted.org Subject: Re: [SSSD-users] problems sssd-1.9.2
On Tue, Nov 13, 2012 at 03:40:14PM +0000, Longina Przybyszewska wrote:
-----Original Message----- From: sssd-users-bounces@lists.fedorahosted.org [mailto:sssd-users-bounces@lists.fedorahosted.org] On Behalf Of Jakub Hrozek Sent: 13. november 2012 14:58 To: sssd-users@lists.fedorahosted.org Subject: Re: [SSSD-users] problems sssd-1.9.2
On Tue, Nov 13, 2012 at 12:44:45PM +0000, Longina Przybyszewska wrote:
Hi, I try sssd-1.9.2 on Ubuntu-Quantal with ad-provider.
You might also be interested in the automounter integration, although I'm not sure that piece of functionality had been backported to Ubuntu yet. The Ubuntu automounter maintainer would know best.
Oh, yes - how stable is automounter integration in the latest stable SSSD? Is I enough to use autofs-5 - or does it need more integration with some SSSD moduls/libraries?
I think the sss support was introduced in autofs 5.0.6, at least in Fedora. I'm actually not quite sure about autofs upstream. You need to look for the lookup_sss.so module.
Until I am lucky to get new packages from Ubuntu maintainers - can I use nsswitch pointing to auto.home maps - would it work with SSSD?
The SSSD integration is provided by the lookup_sss.so module, which is able to talk to the autofs responder process of the SSSD. If your distribution doesn't provide that module, you should still be able to fall back to the LDAP lookups. You just won't be able to leverage the unified configuration in sssd.conf and caching of the maps. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Wed 28 Nov 2012 04:53:54 AM EST, Longina Przybyszewska wrote:
Thanks. I get it finally working!! : Ubuntu-Quantal sssd+ad_provider+NFSv4 - :-)) but still have some issues:
Ticket expires after 10 hours - I run msktutil (application for joining linux to AD and adding principals to the account and some more) daily in crontab to prevent ticket expiration - maybe this is not necessary? Anyway, I ends having to manually reset machine's account and create a new keytab ( it is inefficient, but haven't figured out yet another way) How does sssd renew tickets if machine was offline more then 10 hours?
This is wrong. You don't want to be replacing the keytab. The keytab should not be expiring for weeks or months (or ever, if so configured). What *is* expiring is the ticket-granting ticket (TGT). Instead of using msktutil and replacing the keytab, you should be using 'kinit -k -t /path/to/keytab <host_principal>' to reacquire the TGT.
To get rid off listing of tens of group at login, I use the option:
What do you mean by "listing tens of group"?
ldap_group_member = uniqueMember
It works during login (no more long list, and login delay), but doesn't work when changing personality with 'su -' (again long list of numbers+ login delay)
I have no idea what problem you are trying to solve here.
On Wed 28 Nov 2012 04:53:54 AM EST, Longina Przybyszewska wrote:
Thanks. I get it finally working!! : Ubuntu-Quantal sssd+ad_provider+NFSv4 - :-)) but still have some issues:
Ticket expires after 10 hours - I run msktutil (application for joining linux to AD and adding principals to the account and some more) daily in crontab to prevent ticket expiration - maybe this is not necessary? Anyway, I ends having to manually reset machine's account and create a new keytab ( it is inefficient, but haven't figured out yet another way) How does sssd renew tickets if machine was offline more then 10 hours?
This is wrong. You don't want to be replacing the keytab. The keytab should not be expiring for weeks or months (or ever, if so configured). What *is* expiring is the ticket-granting ticket (TGT). Instead of using msktutil and replacing the keytab, you should be using 'kinit -k -t /path/to/keytab <host_principal>' to reacquire the TGT.
Can sssd do it for me ? Do I miss some options configured properly ?
In the log (krb5_child.log) I can see messages : ...Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment Cannot read [SSSD_KRB5_LIFETIME] from environment
To get rid off listing of tens of group at login, I use the option:
What do you mean by "listing tens of group"?
root@jota:/home/alongina# id longina uid=332405654(longina) gid=332400513 groups=332400513,1172668083,1172671850,1172626924,1172670697,1172632585,1172657894,1172647528,1172673996,1172630281,1172650784,1172649006,1172646018,1172626637,1172668082,1172647518,332406100(nat-esignatur),332403786(nat-terminal-users),1172647527,332405659(imada-terminal-users),1172647519,1172671034,1172652129,1172650787,1172608193,1172646019,1172649007,1172645844,1172630472,1172648739,1172645167,332402830(nat-lectures),1172649004,1172649400,1172671853,1172650786,332408307(dl-nat-it),332402685(common_users),1172645166,1172645845,988802256,1172651920,1172649005,1172659655,1172606592,1172647852,1172633504,1172667765,1172666809,1172645842,1172649046,1172667764,1172647523,1172626846,1172633505,1172645161,1172658369,1172645843,1172616454,1172607216,332411221(nat-pri-setcomputerdesc),1172659249,332410635(nat-it-outlook-admin),1172645163,1172644173,1172670698,988803287,1172645162,1172645841,1172659248,1172666810,1172659262,1172626838,1172647520,988807606,1172626843,332411220(nat-fnc-pri-setdiscription),1172612780,1172649045,1172645152,1172645147,1172626938,1172658370,1172658365,1172630586,1172649398,1172627322,332413664,1172607213,1172626943,1172649060,332408204(nat-it-ansatte),1172632583,1172658364,1172626827,332407177(dl-nat-it-staff),1172658371,1172653861,1172645344,332403699(terminal brugere),1172649061,1172645146,1172632578,1172671847,1172626940,1172626841,1172648741,1172649062,1172632579,1172658363,1172627278,1172645150,1172653860,332411184(nat-booking),332408312(nat-it-ad-hoc),1172632582,1172645145,1172671028,1172645144,1172627767,1172626935,1172632581,1172672165,1172645151,1172671032,332411734(data-nat-nat-it-groupdrive rw),1172657810,1172612322,1172650789,1172648253,1172657811,1172648254,1172649064,1172627766,1172645974,1172672164,1172671286,1172632580,1172648736,1172679679,1172622933,1172679716,1172645975,1172671030,1172620701,1172650191,1172648735
In sssd.conf I use :
ldap_schema = rfc2307bis
ldap_group_member = uniqueMember
The last one doesn't seem to have an effect.
Longina
This is a good question.
Is it wrong?
Computer should always have valid TGT . What happens if computer’s TGT expires – or rather , if it expires does user still have access to all services?
Do I need some tuning in config to prevent that?
I catched in ldap_child.log precise change from preauthentication success--> preauthentication faile
ls –l /etc/krb5.keytab -rw------- 1 root root 894 Nov 07:48 /etc/krb5.keytab
(Thu Nov 29 07:26:54 2012) [[sssd[ldap_child[7809]]]] [main] (0x2000): getting TGT sync (Thu Nov 29 07:26:54 2012) [[sssd[ldap_child[7809]]]] [ldap_child_get_tgt_sync] (0x2000): Kerberos context initialized (Thu Nov 29 07:26:54 2012) [[sssd[ldap_child[7809]]]] [ldap_child_get_tgt_sync] (0x2000): got realm_name: [NAT.C.SDU.DK] (Thu Nov 29 07:26:54 2012) [[sssd[ldap_child[7809]]]] [ldap_child_get_tgt_sync] (0x0100): Principal name is: [VICTORIA$@NAT.C.SDU.DK] (Thu Nov 29 07:26:54 2012) [[sssd[ldap_child[7809]]]] [ldap_child_get_tgt_sync] (0x0100): Using keytab [default] (Thu Nov 29 07:26:54 2012) [[sssd[ldap_child[7809]]]] [ldap_child_get_tgt_sync] (0x2000): keytab ccname: [FILE:/var/lib/sss/db/ccache_NAT.C.SDU.DK] (Thu Nov 29 07:26:54 2012) [[sssd[ldap_child[7809]]]] [ldap_child_get_tgt_sync] (0x2000): credentials initialized (Thu Nov 29 07:26:54 2012) [[sssd[ldap_child[7809]]]] [ldap_child_get_tgt_sync] (0x2000): credentials stored (Thu Nov 29 07:26:54 2012) [[sssd[ldap_child[7809]]]] [ldap_child_get_tgt_sync] (0x2000): Got KDC time offset (Thu Nov 29 07:26:54 2012) [[sssd[ldap_child[7809]]]] [prepare_response] (0x0400): Building response for result [0] (Thu Nov 29 07:26:54 2012) [[sssd[ldap_child[7809]]]] [pack_buffer] (0x2000): response size: 60 (Thu Nov 29 07:26:54 2012) [[sssd[ldap_child[7809]]]] [pack_buffer] (0x1000): result [0] krberr [0] msgsize [40] msg [FILE:/var/lib/sss/db/ccache_NAT.C.SDU.DK] (Thu Nov 29 07:26:54 2012) [[sssd[ldap_child[7809]]]] [main] (0x0400): ldap_child completed successfully (Thu Nov 29 07:46:44 2012) [[sssd[ldap_child[7867]]]] [main] (0x0400): ldap_child started. (Thu Nov 29 07:46:44 2012) [[sssd[ldap_child[7867]]]] [main] (0x2000): context initialized (Thu Nov 29 07:46:44 2012) [[sssd[ldap_child[7867]]]] [unpack_buffer] (0x1000): total buffer size: 37 (Thu Nov 29 07:46:44 2012) [[sssd[ldap_child[7867]]]] [unpack_buffer] (0x1000): realm_str size: 12 Thu Nov 29 07:46:44 2012) [[sssd[ldap_child[7867]]]] [unpack_buffer] (0x1000): got realm_str: NAT.C.SDU.DK (Thu Nov 29 07:46:44 2012) [[sssd[ldap_child[7867]]]] [unpack_buffer] (0x1000): princ_str size: 9 (Thu Nov 29 07:46:44 2012) [[sssd[ldap_child[7867]]]] [unpack_buffer] (0x1000): got princ_str: VICTORIA$ (Thu Nov 29 07:46:44 2012) [[sssd[ldap_child[7867]]]] [unpack_buffer] (0x1000): keytab_name size: 0 (Thu Nov 29 07:46:44 2012) [[sssd[ldap_child[7867]]]] [unpack_buffer] (0x1000): lifetime: 86400 (Thu Nov 29 07:46:44 2012) [[sssd[ldap_child[7867]]]] [main] (0x2000): getting TGT sync: (Thu Nov 29 08:14:09 2012) [[sssd[ldap_child[8137]]]] [unpack_buffer] (0x1000): keytab_name size: 0 (Thu Nov 29 08:14:09 2012) [[sssd[ldap_child[8137]]]] [unpack_buffer] (0x1000): lifetime: 86400 (Thu Nov 29 08:14:09 2012) [[sssd[ldap_child[8137]]]] [main] (0x2000): getting TGT sync (Thu Nov 29 08:14:09 2012) [[sssd[ldap_child[8137]]]] [ldap_child_get_tgt_sync] (0x2000): Kerberos context initialized (Thu Nov 29 08:14:09 2012) [[sssd[ldap_child[8137]]]] [ldap_child_get_tgt_sync] (0x2000): got realm_name: [NAT.C.SDU.DK] (Thu Nov 29 08:14:09 2012) [[sssd[ldap_child[8137]]]] [ldap_child_get_tgt_sync] (0x0100): Principal name is: [VICTORIA$@NAT.C.SDU.DK] (Thu Nov 29 08:14:09 2012) [[sssd[ldap_child[8137]]]] [ldap_child_get_tgt_sync] (0x0100): Using keytab [default] (Thu Nov 29 08:14:09 2012) [[sssd[ldap_child[8137]]]] [ldap_child_get_tgt_sync] (0x2000): keytab ccname: [FILE:/var/lib/sss/db/ccache_NAT.C.SDU.DK] (Thu Nov 29 08:14:09 2012) [[sssd[ldap_child[8137]]]] [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Preauthentication failed (Thu Nov 29 08:14:09 2012) [[sssd[ldap_child[8137]]]] [main] (0x0020): ldap_child_get_tgt_sync failed. (Thu Nov 29 08:14:09 2012) [[sssd[ldap_child[8137]]]] [prepare_response] (0x0400): Building response for result [-1765328360] (Thu Nov 29 08:14:09 2012) [[sssd[ldap_child[8137]]]] [pack_buffer] (0x2000): response size: 44 (Thu Nov 29 08:14:09 2012) [[sssd[ldap_child[8137]]]] [pack_buffer] (0x1000): result [14] krberr [-1765328360] msgsize [24] msg [Preauthentication failed] (Thu Nov 29 08:14:09 2012) [[sssd[ldap_child[8137]]]] [main] (0x0400): ldap_child completed successfully (Thu Nov 29 08:14:09 2012) [[sssd[ldap_child[8138]]]] [main] (0x0400): ldap_child started.
Longina From: sssd-users-bounces@lists.fedorahosted.org [mailto:sssd-users-bounces@lists.fedorahosted.org] On Behalf Of Ondrej Valousek Sent: 29. november 2012 14:27 To: sssd-users@lists.fedorahosted.org Subject: Re: [SSSD-users] problems sssd-1.9.2
Why do you need a TGT generated from a machine account principal? Use your own instead.
O.
On 11/29/2012 12:12 PM, Longina Przybyszewska wrote:
Can sssd do it for me ? Do I miss some options configured properly ?
On 11/30/2012 10:09 AM, Longina Przybyszewska wrote:
This is a good question.
Is it wrong?
Computer should always have valid TGT .
What happens if computer’s TGT expires – or rather , if it expires does user still have access to all services?
Do I need some tuning in config to prevent that?
I catched in ldap_child.log precise change from preauthentication successàpreauthentication faile
ls –l /etc/krb5.keytab
-rw------- 1 root root 894 Nov 07:48 /etc/krb5.keytab
If you are asking in the context of SSSD then SSSD just handles the renewal of the ticket for the host automatically for its purposes only. But this does not mean that it makes sure that host TGT is always available. Do you need to use host TGT for something else other than SSSD for example for cron jobs? If so then you need to periodically do kinit with host principal using host keytab. In future there will be a process called GSS proxy that would be able to do it on demand on your behalf.
(Thu Nov 29 07:26:54 2012) [[sssd[ldap_child[7809]]]] [main] (0x2000): getting TGT sync
(Thu Nov 29 07:26:54 2012) [[sssd[ldap_child[7809]]]] [ldap_child_get_tgt_sync] (0x2000): Kerberos context initialized
(Thu Nov 29 07:26:54 2012) [[sssd[ldap_child[7809]]]] [ldap_child_get_tgt_sync] (0x2000): got realm_name: [NAT.C.SDU.DK]
(Thu Nov 29 07:26:54 2012) [[sssd[ldap_child[7809]]]] [ldap_child_get_tgt_sync] (0x0100): Principal name is: [VICTORIA$@NAT.C.SDU.DK]
(Thu Nov 29 07:26:54 2012) [[sssd[ldap_child[7809]]]] [ldap_child_get_tgt_sync] (0x0100): Using keytab [default]
(Thu Nov 29 07:26:54 2012) [[sssd[ldap_child[7809]]]] [ldap_child_get_tgt_sync] (0x2000): keytab ccname: [FILE:/var/lib/sss/db/ccache_NAT.C.SDU.DK]
(Thu Nov 29 07:26:54 2012) [[sssd[ldap_child[7809]]]] [ldap_child_get_tgt_sync] (0x2000): credentials initialized
(Thu Nov 29 07:26:54 2012) [[sssd[ldap_child[7809]]]] [ldap_child_get_tgt_sync] (0x2000): credentials stored
(Thu Nov 29 07:26:54 2012) [[sssd[ldap_child[7809]]]] [ldap_child_get_tgt_sync] (0x2000): Got KDC time offset
(Thu Nov 29 07:26:54 2012) [[sssd[ldap_child[7809]]]] [prepare_response] (0x0400): Building response for result [0]
(Thu Nov 29 07:26:54 2012) [[sssd[ldap_child[7809]]]] [pack_buffer] (0x2000): response size: 60
(Thu Nov 29 07:26:54 2012) [[sssd[ldap_child[7809]]]] [pack_buffer] (0x1000): result [0] krberr [0] msgsize [40] msg [FILE:/var/lib/sss/db/ccache_NAT.C.SDU.DK]
(Thu Nov 29 07:26:54 2012) [[sssd[ldap_child[7809]]]] [main] (0x0400): ldap_child completed successfully
(Thu Nov 29 07:46:44 2012) [[sssd[ldap_child[7867]]]] [main] (0x0400): ldap_child started.
(Thu Nov 29 07:46:44 2012) [[sssd[ldap_child[7867]]]] [main] (0x2000): context initialized
(Thu Nov 29 07:46:44 2012) [[sssd[ldap_child[7867]]]] [unpack_buffer] (0x1000): total buffer size: 37
(Thu Nov 29 07:46:44 2012) [[sssd[ldap_child[7867]]]] [unpack_buffer] (0x1000): realm_str size: 12
Thu Nov 29 07:46:44 2012) [[sssd[ldap_child[7867]]]] [unpack_buffer] (0x1000): got realm_str: NAT.C.SDU.DK
(Thu Nov 29 07:46:44 2012) [[sssd[ldap_child[7867]]]] [unpack_buffer] (0x1000): princ_str size: 9
(Thu Nov 29 07:46:44 2012) [[sssd[ldap_child[7867]]]] [unpack_buffer] (0x1000): got princ_str: VICTORIA$
(Thu Nov 29 07:46:44 2012) [[sssd[ldap_child[7867]]]] [unpack_buffer] (0x1000): keytab_name size: 0
(Thu Nov 29 07:46:44 2012) [[sssd[ldap_child[7867]]]] [unpack_buffer] (0x1000): lifetime: 86400
(Thu Nov 29 07:46:44 2012) [[sssd[ldap_child[7867]]]] [main] (0x2000): getting TGT sync:
(Thu Nov 29 08:14:09 2012) [[sssd[ldap_child[8137]]]] [unpack_buffer] (0x1000): keytab_name size: 0
(Thu Nov 29 08:14:09 2012) [[sssd[ldap_child[8137]]]] [unpack_buffer] (0x1000): lifetime: 86400
(Thu Nov 29 08:14:09 2012) [[sssd[ldap_child[8137]]]] [main] (0x2000): getting TGT sync
(Thu Nov 29 08:14:09 2012) [[sssd[ldap_child[8137]]]] [ldap_child_get_tgt_sync] (0x2000): Kerberos context initialized
(Thu Nov 29 08:14:09 2012) [[sssd[ldap_child[8137]]]] [ldap_child_get_tgt_sync] (0x2000): got realm_name: [NAT.C.SDU.DK]
(Thu Nov 29 08:14:09 2012) [[sssd[ldap_child[8137]]]] [ldap_child_get_tgt_sync] (0x0100): Principal name is: [VICTORIA$@NAT.C.SDU.DK]
(Thu Nov 29 08:14:09 2012) [[sssd[ldap_child[8137]]]] [ldap_child_get_tgt_sync] (0x0100): Using keytab [default]
(Thu Nov 29 08:14:09 2012) [[sssd[ldap_child[8137]]]] [ldap_child_get_tgt_sync] (0x2000): keytab ccname: [FILE:/var/lib/sss/db/ccache_NAT.C.SDU.DK]
(Thu Nov 29 08:14:09 2012) [[sssd[ldap_child[8137]]]] [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Preauthentication failed
(Thu Nov 29 08:14:09 2012) [[sssd[ldap_child[8137]]]] [main] (0x0020): ldap_child_get_tgt_sync failed.
(Thu Nov 29 08:14:09 2012) [[sssd[ldap_child[8137]]]] [prepare_response] (0x0400): Building response for result [-1765328360]
(Thu Nov 29 08:14:09 2012) [[sssd[ldap_child[8137]]]] [pack_buffer] (0x2000): response size: 44
(Thu Nov 29 08:14:09 2012) [[sssd[ldap_child[8137]]]] [pack_buffer] (0x1000): result [14] krberr [-1765328360] msgsize [24] msg [Preauthentication failed]
(Thu Nov 29 08:14:09 2012) [[sssd[ldap_child[8137]]]] [main] (0x0400): ldap_child completed successfully
(Thu Nov 29 08:14:09 2012) [[sssd[ldap_child[8138]]]] [main] (0x0400): ldap_child started.
Longina
*From:*sssd-users-bounces@lists.fedorahosted.org [mailto:sssd-users-bounces@lists.fedorahosted.org] *On Behalf Of *Ondrej Valousek *Sent:* 29. november 2012 14:27 *To:* sssd-users@lists.fedorahosted.org *Subject:* Re: [SSSD-users] problems sssd-1.9.2
Why do you need a TGT generated from a machine account principal? Use your own instead.
O.
On 11/29/2012 12:12 PM, Longina Przybyszewska wrote:
Can sssd do it for me ? Do I miss some options configured properly ?
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
sssd-users@lists.fedorahosted.org
-
Dmitri Pal -
Jakub Hrozek -
Longina Przybyszewska -
Ondrej Valousek -
Stephen Gallagher