On Wed, Apr 23, 2014 at 08:10:47AM +0200, Paul Liljenberg wrote:
- Notice: I sent this email to the list using another mail address, which i
*>>* believe whas not verified properly. If this emali is properly sent to the *>>* list you can disregard moderating the message. *>> >>* Hello *>> >>* Im setting up a single signon solution for about 1200 servers. The *>>* situation as it seems is that we are setting up all users in a windows 2008 *>>* r2 active directory, adding proper unix permissions. A user with proper *>>* priveliges to read active directory is being used by sssd to read which *>>* users is allowed in and not. If the users does not have a home directory *>>* they are being created automatically. So whats the issue here? Access to *>>* the system does not happen instantanely and i believe its because sssd is *>>* polling active directory every 120 seconds. It seems as if it has issues *>>* remaining its state and it is just as if it would loose its local database. *>>* I would like to be able to have users being logged directly after a user is *>>* being added to active directory. Is this possible and how could this be *>>* achieved? *
I would encourage you to turn enumeration off. Enumeration is a background task that periodically downloads and saves all users from the server, which can be very intensitve especially for large environments.
Also, is there a reason to use a bind user and a password and not a keytab and then leverage GSSAPI?
We have some howtos on enrolling a client with AD for pre-1.9 clients: https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20...
And also for 1.9 and later (recommended): https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server
Ive edit the configuration to not use enumeration. The goal is to use GSSAPI to. For some reason it refuses logins. It does not give me any helpful ouput to fix it.
conf:
[sssd] config_file_version = 2 domains = INT.HOME.LAN services = nss, pam debug_level = 0
[nss] filter_groups = root filter_users = root reconnection_retries = 3
[pam] reconnection_retries = 3
[domain/INT.HOME.LAN] # Unless you know you need referrals, turn them off ldap_referrals = false # Uncomment if you need offline logins cache_credentials = true enumerate = false
id_provider = ldap auth_provider = krb5 chpass_provider = krb5 access_provider = ldap
# Uncomment if service discovery is not working ldap_uri = ldap://vagrant-2008r2.int.home.lan
# Comment out if not using SASL/GSSAPI to bind ldap_sasl_mech = GSSAPI # Uncomment and adjust if the default principal host/fqdn at REALM is not available #ldap_sasl_authid = nfs/client.ad.example.com at AD.EXAMPLE.COMhttp://ad.example.com/
# Define these only if anonymous binds are not allowed and no keytab is available # Enabling use_start_tls is very important, otherwise the bind password is transmitted # over the network in the clear #ldap_id_use_start_tls = True #ldap_default_bind_dn = CN=test,CN=Users,DC=int,DC=home,DC=local #ldap_default_authtok_type = password #ldap_default_authtok = secretpassword
ldap_schema = rfc2307bis
ldap_user_search_base = CN=Users,DC=int,DC=home,DC=lan ldap_user_object_class = user
ldap_user_home_directory = unixHomeDirectory ldap_user_principal = userPrincipalName
ldap_group_search_base = CN=linuxadmins,DC=int,DC=home,DC=lan ldap_group_object_class = group
#ldap_access_filter = memberOf=cn=linuxadmins,dc=int,dc=home,dc=lan
ldap_access_order = expire ldap_account_expire_policy = ad ldap_force_upper_case_realm = true #ldap_krb5_init_creds = true
# Uncomment if dns discovery of your AD servers isn't working. #krb5_server = 192.168.3.11 krb5_realm = INT.HOME.LAN #krb5_keytab = /etc/krb5.keytab
# Probably required with sssd 1.8.x and newer krb5_canonicalize = false
# Perhaps you need to redirect to certain attributes? #ldap_user_object_class = user #ldap_user_name = sAMAccountName #ldap_user_uid_number = msSFU30UidNumber #ldap_user_gid_number = msSFU30GidNumber #ldap_user_gecos = displayName #ldap_user_home_directory = msSFU30HomeDirectory #ldap_user_shell = msSFU30LoginShell #ldap_user_principal = userPrincipalName #ldap_group_object_class = group #ldap_group_name = cn #ldap_group_gid_number = msSFU30GidNumber
error output:
(Fri May 2 08:45:01 2014) [sssd[nss]] [nss_cmd_getpwnam] (0x0100): Requesting info for [paul1] from [<ALL>] (Fri May 2 08:45:01 2014) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [paul1@INT.HOME.LAN] (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=paul1] (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'LDAP' (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 'vagrant-2008r2.int.home.lan' in files (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [set_server_common_status] (0x0100): Marking server 'vagrant-2008r2.int.home.lan' as 'resolving name' (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve AAAA record of 'vagrant-2008r2.int.home.lan' in files (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [resolv_gethostbyname_next] (0x0200): No more address families to retry (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record of 'vagrant-2008r2.int.home.lan' in DNS (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [set_server_common_status] (0x0100): Marking server 'vagrant-2008r2.int.home.lan' as 'name resolved' (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [be_resolve_server_done] (0x0200): Found address for server vagrant-2008r2.int.home.lan: [192.168.3.2] TTL 3600 (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [get_naming_context] (0x0200): Using value from [defaultNamingContext] as naming context. (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [sdap_set_search_base] (0x0100): Setting option [ldap_search_base] to [DC=int,DC=home,DC=lan]. (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [common_parse_search_base] (0x0100): Search base added: [DEFAULT][DC=int,DC=home,DC=lan][SUBTREE][] (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [sdap_set_search_base] (0x0100): Setting option [ldap_netgroup_search_base] to [DC=int,DC=home,DC=lan]. (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [common_parse_search_base] (0x0100): Search base added: [NETGROUP][DC=int,DC=home,DC=lan][SUBTREE][] (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [sdap_set_search_base] (0x0100): Setting option [ldap_sudo_search_base] to [DC=int,DC=home,DC=lan]. (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [common_parse_search_base] (0x0100): Search base added: [SUDO][DC=int,DC=home,DC=lan][SUBTREE][] (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [sdap_set_search_base] (0x0100): Setting option [ldap_service_search_base] to [DC=int,DC=home,DC=lan]. (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [common_parse_search_base] (0x0100): Search base added: [SERVICE][DC=int,DC=home,DC=lan][SUBTREE][] (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [sdap_set_search_base] (0x0100): Setting option [ldap_autofs_search_base] to [DC=int,DC=home,DC=lan]. (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [common_parse_search_base] (0x0100): Search base added: [AUTOFS][DC=int,DC=home,DC=lan][SUBTREE][] (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'KERBEROS' (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 'client' in files (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [resolve_srv_cont] (0x0100): Searching for servers via SRV query '_KERBEROS._udp.int.home.lan' (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [resolv_getsrv_send] (0x0100): Trying to resolve SRV record of '_KERBEROS._udp.int.home.lan' (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [set_srv_data_status] (0x0100): Marking SRV lookup of service 'KERBEROS' as 'resolved' (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [be_resolve_server_done] (0x0200): Found address for server vagrant-2008r2.int.home.lan: [192.168.3.2] TTL 3600 (Fri May 2 08:45:01 2014) [[sssd[ldap_child[5745]]]] [select_principal_from_keytab] (0x0200): trying to select the most appropriate principal from keytab (Fri May 2 08:45:01 2014) [[sssd[ldap_child[5745]]]] [select_principal_from_keytab] (0x0200): Selected principal: CLIENT$@INT.HOME.LAN (Fri May 2 08:45:01 2014) [[sssd[ldap_child[5745]]]] [ldap_child_get_tgt_sync] (0x0100): Principal name is: [CLIENT$@INT.HOME.LAN] (Fri May 2 08:45:01 2014) [[sssd[ldap_child[5745]]]] [ldap_child_get_tgt_sync] (0x0200): Loaded 4 enctypes from keytab for CLIENT$@INT.HOME.LAN (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [sasl_bind_send] (0x0100): Executing sasl bind mech: GSSAPI, user: (null) (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [child_sig_handler] (0x0100): child [5745] finished successfully. (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'vagrant-2008r2.int.home.lan' as 'working' (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [set_server_common_status] (0x0100): Marking server 'vagrant-2008r2.int.home.lan' as 'working' (Fri May 2 08:45:01 2014) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [paul1@INT.HOME.LAN] (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Fri May 2 08:45:04 2014) [sssd] [service_send_ping] (0x0100): Pinging INT.HOME.LAN (Fri May 2 08:45:04 2014) [sssd] [service_send_ping] (0x0100): Pinging nss (Fri May 2 08:45:04 2014) [sssd] [service_send_ping] (0x0100): Pinging pam
On Fri, May 02, 2014 at 08:47:48AM +0200, Paul Liljenberg wrote:
On Wed, Apr 23, 2014 at 08:10:47AM +0200, Paul Liljenberg wrote:
- Notice: I sent this email to the list using another mail address, which i
*>>* believe whas not verified properly. If this emali is properly sent to the *>>* list you can disregard moderating the message. *>> >>* Hello *>> >>* Im setting up a single signon solution for about 1200 servers. The *>>* situation as it seems is that we are setting up all users in a windows 2008 *>>* r2 active directory, adding proper unix permissions. A user with proper *>>* priveliges to read active directory is being used by sssd to read which *>>* users is allowed in and not. If the users does not have a home directory *>>* they are being created automatically. So whats the issue here? Access to *>>* the system does not happen instantanely and i believe its because sssd is *>>* polling active directory every 120 seconds. It seems as if it has issues *>>* remaining its state and it is just as if it would loose its local database. *>>* I would like to be able to have users being logged directly after a user is *>>* being added to active directory. Is this possible and how could this be *>>* achieved?
I would encourage you to turn enumeration off. Enumeration is a background task that periodically downloads and saves all users from the server, which can be very intensitve especially for large environments.
Also, is there a reason to use a bind user and a password and not a keytab and then leverage GSSAPI?
We have some howtos on enrolling a client with AD for pre-1.9 clients: https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20...
And also for 1.9 and later (recommended): https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server
Ive edit the configuration to not use enumeration. The goal is to use GSSAPI to. For some reason it refuses logins. It does not give me any helpful ouput to fix it.
conf:
[sssd] config_file_version = 2 domains = INT.HOME.LAN services = nss, pam debug_level = 0
[nss] filter_groups = root filter_users = root reconnection_retries = 3
[pam] reconnection_retries = 3
[domain/INT.HOME.LAN] # Unless you know you need referrals, turn them off ldap_referrals = false # Uncomment if you need offline logins cache_credentials = true enumerate = false
id_provider = ldap auth_provider = krb5 chpass_provider = krb5 access_provider = ldap
# Uncomment if service discovery is not working ldap_uri = ldap://vagrant-2008r2.int.home.lan
# Comment out if not using SASL/GSSAPI to bind ldap_sasl_mech = GSSAPI # Uncomment and adjust if the default principal host/fqdn at REALM is not available #ldap_sasl_authid = nfs/client.ad.example.com at AD.EXAMPLE.COMhttp://ad.example.com/
# Define these only if anonymous binds are not allowed and no keytab is available # Enabling use_start_tls is very important, otherwise the bind password is transmitted # over the network in the clear #ldap_id_use_start_tls = True #ldap_default_bind_dn = CN=test,CN=Users,DC=int,DC=home,DC=local #ldap_default_authtok_type = password #ldap_default_authtok = secretpassword
ldap_schema = rfc2307bis
ldap_user_search_base = CN=Users,DC=int,DC=home,DC=lan ldap_user_object_class = user
ldap_user_home_directory = unixHomeDirectory ldap_user_principal = userPrincipalName
ldap_group_search_base = CN=linuxadmins,DC=int,DC=home,DC=lan ldap_group_object_class = group
#ldap_access_filter = memberOf=cn=linuxadmins,dc=int,dc=home,dc=lan
ldap_access_order = expire ldap_account_expire_policy = ad ldap_force_upper_case_realm = true #ldap_krb5_init_creds = true
# Uncomment if dns discovery of your AD servers isn't working. #krb5_server = 192.168.3.11 krb5_realm = INT.HOME.LAN #krb5_keytab = /etc/krb5.keytab
# Probably required with sssd 1.8.x and newer krb5_canonicalize = false
# Perhaps you need to redirect to certain attributes? #ldap_user_object_class = user #ldap_user_name = sAMAccountName #ldap_user_uid_number = msSFU30UidNumber #ldap_user_gid_number = msSFU30GidNumber #ldap_user_gecos = displayName #ldap_user_home_directory = msSFU30HomeDirectory #ldap_user_shell = msSFU30LoginShell #ldap_user_principal = userPrincipalName #ldap_group_object_class = group #ldap_group_name = cn #ldap_group_gid_number = msSFU30GidNumber
error output:
Did you trim the debug log maybe? It seems incomplete..
(Fri May 2 08:45:01 2014) [sssd[nss]] [nss_cmd_getpwnam] (0x0100): Requesting info for [paul1] from [<ALL>] (Fri May 2 08:45:01 2014) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [paul1@INT.HOME.LAN]
The frontend searches for paul1 in INT.HOME.LAN ^
(Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=paul1]
Queries the backend ^
(Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'LDAP' (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 'vagrant-2008r2.int.home.lan' in files (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [set_server_common_status] (0x0100): Marking server 'vagrant-2008r2.int.home.lan' as 'resolving name' (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve AAAA record of 'vagrant-2008r2.int.home.lan' in files (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [resolv_gethostbyname_next] (0x0200): No more address families to retry (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record of 'vagrant-2008r2.int.home.lan' in DNS (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [set_server_common_status] (0x0100): Marking server 'vagrant-2008r2.int.home.lan' as 'name resolved' (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [be_resolve_server_done] (0x0200): Found address for server vagrant-2008r2.int.home.lan: [192.168.3.2] TTL 3600
Backend resolved DNS, starts connecting ^
(Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [get_naming_context] (0x0200): Using value from [defaultNamingContext] as naming context. (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [sdap_set_search_base] (0x0100): Setting option [ldap_search_base] to [DC=int,DC=home,DC=lan]. (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [common_parse_search_base] (0x0100): Search base added: [DEFAULT][DC=int,DC=home,DC=lan][SUBTREE][] (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [sdap_set_search_base] (0x0100): Setting option [ldap_netgroup_search_base] to [DC=int,DC=home,DC=lan]. (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [common_parse_search_base] (0x0100): Search base added: [NETGROUP][DC=int,DC=home,DC=lan][SUBTREE][] (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [sdap_set_search_base] (0x0100): Setting option [ldap_sudo_search_base] to [DC=int,DC=home,DC=lan]. (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [common_parse_search_base] (0x0100): Search base added: [SUDO][DC=int,DC=home,DC=lan][SUBTREE][] (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [sdap_set_search_base] (0x0100): Setting option [ldap_service_search_base] to [DC=int,DC=home,DC=lan]. (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [common_parse_search_base] (0x0100): Search base added: [SERVICE][DC=int,DC=home,DC=lan][SUBTREE][] (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [sdap_set_search_base] (0x0100): Setting option [ldap_autofs_search_base] to [DC=int,DC=home,DC=lan]. (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [common_parse_search_base] (0x0100): Search base added: [AUTOFS][DC=int,DC=home,DC=lan][SUBTREE][] (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'KERBEROS' (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 'client' in files (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [resolve_srv_cont] (0x0100): Searching for servers via SRV query '_KERBEROS._udp.int.home.lan' (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [resolv_getsrv_send] (0x0100): Trying to resolve SRV record of '_KERBEROS._udp.int.home.lan' (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [set_srv_data_status] (0x0100): Marking SRV lookup of service 'KERBEROS' as 'resolved' (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [be_resolve_server_done] (0x0200): Found address for server vagrant-2008r2.int.home.lan: [192.168.3.2] TTL 3600 (Fri May 2 08:45:01 2014) [[sssd[ldap_child[5745]]]] [select_principal_from_keytab] (0x0200): trying to select the most appropriate principal from keytab (Fri May 2 08:45:01 2014) [[sssd[ldap_child[5745]]]] [select_principal_from_keytab] (0x0200): Selected principal: CLIENT$@INT.HOME.LAN (Fri May 2 08:45:01 2014) [[sssd[ldap_child[5745]]]] [ldap_child_get_tgt_sync] (0x0100): Principal name is: [CLIENT$@INT.HOME.LAN] (Fri May 2 08:45:01 2014) [[sssd[ldap_child[5745]]]] [ldap_child_get_tgt_sync] (0x0200): Loaded 4 enctypes from keytab for CLIENT$@INT.HOME.LAN (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [sasl_bind_send] (0x0100): Executing sasl bind mech: GSSAPI, user: (null) (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [child_sig_handler] (0x0100): child [5745] finished successfully. (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'vagrant-2008r2.int.home.lan' as 'working' (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [set_server_common_status] (0x0100): Marking server 'vagrant-2008r2.int.home.lan' as 'working'
Backend authenticated with the server successfully. Here I would expect to see the LDAP search for the user, is it not there?
(Fri May 2 08:45:01 2014) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [paul1@INT.HOME.LAN] (Fri May 2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Fri May 2 08:45:04 2014) [sssd] [service_send_ping] (0x0100): Pinging INT.HOME.LAN (Fri May 2 08:45:04 2014) [sssd] [service_send_ping] (0x0100): Pinging nss (Fri May 2 08:45:04 2014) [sssd] [service_send_ping] (0x0100): Pinging pam
On Fri, 2014-05-02 at 08:47 +0200, Paul Liljenberg wrote:
On Wed, Apr 23, 2014 at 08:10:47AM +0200, Paul Liljenberg wrote:
Notice: I sent this email to the list using another mail address, which i believe whas not verified properly. If this emali is properly sent to the list you can disregard moderating the message.
Hello
Im setting up a single signon solution for about 1200 servers. The situation as it seems is that we are setting up all users in a windows 2008 r2 active directory, adding proper unix permissions. A user with proper priveliges to read active directory is being used by sssd to read which users is allowed in and not. If the users does not have a home directory they are being created automatically. So whats the issue here? Access to the system does not happen instantanely and i believe its because sssd is polling active directory every 120 seconds. It seems as if it has issues remaining its state and it is just as if it would loose its local database. I would like to be able to have users being logged directly after a user is being added to active directory. Is this possible and how could this be achieved?
I would encourage you to turn enumeration off. Enumeration is a background task that periodically downloads and saves all users from the server, which can be very intensitve especially for large environments.
Also, is there a reason to use a bind user and a password and not a keytab and then leverage GSSAPI?
We have some howtos on enrolling a client with AD for pre-1.9 clients: https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20...
And also for 1.9 and later (recommended): https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server
Ive edit the configuration to not use enumeration. The goal is to use GSSAPI to. For some reason it refuses logins. It does not give me any helpful ouput to fix it.
conf:
[sssd] config_file_version = 2 domains = INT.HOME.LAN services = nss, pam debug_level = 0
[nss] filter_groups = root filter_users = root reconnection_retries = 3
[pam] reconnection_retries = 3
[domain/INT.HOME.LAN] # Unless you know you need referrals, turn them off ldap_referrals = false # Uncomment if you need offline logins cache_credentials = true enumerate = false
id_provider = ldap auth_provider = krb5 chpass_provider = krb5 access_provider = ldap
# Uncomment if service discovery is not working ldap_uri = ldap://vagrant-2008r2.int.home.lan
# Comment out if not using SASL/GSSAPI to bind ldap_sasl_mech = GSSAPI # Uncomment and adjust if the default principal host/fqdn at REALM is not available #ldap_sasl_authid = nfs/client.ad.example.com at AD.EXAMPLE.COM
# Define these only if anonymous binds are not allowed and no keytab is available # Enabling use_start_tls is very important, otherwise the bind password is transmitted # over the network in the clear #ldap_id_use_start_tls = True #ldap_default_bind_dn = CN=test,CN=Users,DC=int,DC=home,DC=local #ldap_default_authtok_type = password #ldap_default_authtok = secretpassword
ldap_schema = rfc2307bis
ldap_user_search_base = CN=Users,DC=int,DC=home,DC=lan ldap_user_object_class = user
ldap_user_home_directory = unixHomeDirectory ldap_user_principal = userPrincipalName
ldap_group_search_base = CN=linuxadmins,DC=int,DC=home,DC=lan ldap_group_object_class = group
#ldap_access_filter = memberOf=cn=linuxadmins,dc=int,dc=home,dc=lan
ldap_access_order = expire ldap_account_expire_policy = ad ldap_force_upper_case_realm = true #ldap_krb5_init_creds = true
# Uncomment if dns discovery of your AD servers isn't working. #krb5_server = 192.168.3.11 krb5_realm = INT.HOME.LAN #krb5_keytab = /etc/krb5.keytab
# Probably required with sssd 1.8.x and newer krb5_canonicalize = false
# Perhaps you need to redirect to certain attributes? #ldap_user_object_class = user #ldap_user_name = sAMAccountName #ldap_user_uid_number = msSFU30UidNumber #ldap_user_gid_number = msSFU30GidNumber #ldap_user_gecos = displayName #ldap_user_home_directory = msSFU30HomeDirectory #ldap_user_shell = msSFU30LoginShell #ldap_user_principal = userPrincipalName #ldap_group_object_class = group #ldap_group_name = cn #ldap_group_gid_number = msSFU30GidNumber
Hi Can you upgrade to a more recent version and use the new ad backend?
If not, remember that the older versions didn't map the ad attributes to something we could recognise. sAMAccountName as being the Linux username is one I remember off the top of my head. Also, don't assume defaults. uncomment the lines until you get it working. We've a 1.9 config against AD here: http://linuxcostablanca.blogspot.com.es/2013/04/sssd-in-samba-40.html HTH Steve
On Fri, May 02, 2014 at 10:32:10AM +0200, steve wrote:
On Fri, 2014-05-02 at 08:47 +0200, Paul Liljenberg wrote:
On Wed, Apr 23, 2014 at 08:10:47AM +0200, Paul Liljenberg wrote:
Notice: I sent this email to the list using another mail address, which i believe whas not verified properly. If this emali is properly sent to the list you can disregard moderating the message.
Hello
Im setting up a single signon solution for about 1200 servers. The situation as it seems is that we are setting up all users in a windows 2008 r2 active directory, adding proper unix permissions. A user with proper priveliges to read active directory is being used by sssd to read which users is allowed in and not. If the users does not have a home directory they are being created automatically. So whats the issue here? Access to the system does not happen instantanely and i believe its because sssd is polling active directory every 120 seconds. It seems as if it has issues remaining its state and it is just as if it would loose its local database. I would like to be able to have users being logged directly after a user is being added to active directory. Is this possible and how could this be achieved?
I would encourage you to turn enumeration off. Enumeration is a background task that periodically downloads and saves all users from the server, which can be very intensitve especially for large environments.
Also, is there a reason to use a bind user and a password and not a keytab and then leverage GSSAPI?
We have some howtos on enrolling a client with AD for pre-1.9 clients: https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20...
And also for 1.9 and later (recommended): https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server
Ive edit the configuration to not use enumeration. The goal is to use GSSAPI to. For some reason it refuses logins. It does not give me any helpful ouput to fix it.
conf:
[sssd] config_file_version = 2 domains = INT.HOME.LAN services = nss, pam debug_level = 0
[nss] filter_groups = root filter_users = root reconnection_retries = 3
[pam] reconnection_retries = 3
[domain/INT.HOME.LAN] # Unless you know you need referrals, turn them off ldap_referrals = false # Uncomment if you need offline logins cache_credentials = true enumerate = false
id_provider = ldap auth_provider = krb5 chpass_provider = krb5 access_provider = ldap
# Uncomment if service discovery is not working ldap_uri = ldap://vagrant-2008r2.int.home.lan
# Comment out if not using SASL/GSSAPI to bind ldap_sasl_mech = GSSAPI # Uncomment and adjust if the default principal host/fqdn at REALM is not available #ldap_sasl_authid = nfs/client.ad.example.com at AD.EXAMPLE.COM
# Define these only if anonymous binds are not allowed and no keytab is available # Enabling use_start_tls is very important, otherwise the bind password is transmitted # over the network in the clear #ldap_id_use_start_tls = True #ldap_default_bind_dn = CN=test,CN=Users,DC=int,DC=home,DC=local #ldap_default_authtok_type = password #ldap_default_authtok = secretpassword
ldap_schema = rfc2307bis
ldap_user_search_base = CN=Users,DC=int,DC=home,DC=lan ldap_user_object_class = user
ldap_user_home_directory = unixHomeDirectory ldap_user_principal = userPrincipalName
ldap_group_search_base = CN=linuxadmins,DC=int,DC=home,DC=lan ldap_group_object_class = group
#ldap_access_filter = memberOf=cn=linuxadmins,dc=int,dc=home,dc=lan
ldap_access_order = expire ldap_account_expire_policy = ad ldap_force_upper_case_realm = true #ldap_krb5_init_creds = true
# Uncomment if dns discovery of your AD servers isn't working. #krb5_server = 192.168.3.11 krb5_realm = INT.HOME.LAN #krb5_keytab = /etc/krb5.keytab
# Probably required with sssd 1.8.x and newer krb5_canonicalize = false
# Perhaps you need to redirect to certain attributes? #ldap_user_object_class = user #ldap_user_name = sAMAccountName #ldap_user_uid_number = msSFU30UidNumber #ldap_user_gid_number = msSFU30GidNumber #ldap_user_gecos = displayName #ldap_user_home_directory = msSFU30HomeDirectory #ldap_user_shell = msSFU30LoginShell #ldap_user_principal = userPrincipalName #ldap_group_object_class = group #ldap_group_name = cn #ldap_group_gid_number = msSFU30GidNumber
Hi Can you upgrade to a more recent version and use the new ad backend?
If not, remember that the older versions didn't map the ad attributes to something we could recognise. sAMAccountName as being the Linux username is one I remember off the top of my head. Also, don't assume defaults. uncomment the lines until you get it working. We've a 1.9 config against AD here: http://linuxcostablanca.blogspot.com.es/2013/04/sssd-in-samba-40.html HTH Steve
Right, the mappings might need to be adjusted, depending on the environment. The upstream guide for the LDAP provider is here: https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20...
On Fri, 2014-05-02 at 10:38 +0200, Jakub Hrozek wrote:
On Fri, May 02, 2014 at 10:32:10AM +0200, steve wrote:
On Fri, 2014-05-02 at 08:47 +0200, Paul Liljenberg wrote:
On Wed, Apr 23, 2014 at 08:10:47AM +0200, Paul Liljenberg wrote:
Notice: I sent this email to the list using another mail address, which i believe whas not verified properly. If this emali is properly sent to the list you can disregard moderating the message.
Hello
Im setting up a single signon solution for about 1200 servers. The situation as it seems is that we are setting up all users in a windows 2008 r2 active directory, adding proper unix permissions. A user with proper priveliges to read active directory is being used by sssd to read which users is allowed in and not. If the users does not have a home directory they are being created automatically. So whats the issue here? Access to the system does not happen instantanely and i believe its because sssd is polling active directory every 120 seconds. It seems as if it has issues remaining its state and it is just as if it would loose its local database. I would like to be able to have users being logged directly after a user is being added to active directory. Is this possible and how could this be achieved?
I would encourage you to turn enumeration off. Enumeration is a background task that periodically downloads and saves all users from the server, which can be very intensitve especially for large environments.
Also, is there a reason to use a bind user and a password and not a keytab and then leverage GSSAPI?
We have some howtos on enrolling a client with AD for pre-1.9 clients: https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20...
And also for 1.9 and later (recommended): https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server
Ive edit the configuration to not use enumeration. The goal is to use GSSAPI to. For some reason it refuses logins. It does not give me any helpful ouput to fix it.
conf:
[sssd] config_file_version = 2 domains = INT.HOME.LAN services = nss, pam debug_level = 0
[nss] filter_groups = root filter_users = root reconnection_retries = 3
[pam] reconnection_retries = 3
[domain/INT.HOME.LAN] # Unless you know you need referrals, turn them off ldap_referrals = false # Uncomment if you need offline logins cache_credentials = true enumerate = false
id_provider = ldap auth_provider = krb5 chpass_provider = krb5 access_provider = ldap
# Uncomment if service discovery is not working ldap_uri = ldap://vagrant-2008r2.int.home.lan
# Comment out if not using SASL/GSSAPI to bind ldap_sasl_mech = GSSAPI # Uncomment and adjust if the default principal host/fqdn at REALM is not available #ldap_sasl_authid = nfs/client.ad.example.com at AD.EXAMPLE.COM
# Define these only if anonymous binds are not allowed and no keytab is available # Enabling use_start_tls is very important, otherwise the bind password is transmitted # over the network in the clear #ldap_id_use_start_tls = True #ldap_default_bind_dn = CN=test,CN=Users,DC=int,DC=home,DC=local #ldap_default_authtok_type = password #ldap_default_authtok = secretpassword
ldap_schema = rfc2307bis
ldap_user_search_base = CN=Users,DC=int,DC=home,DC=lan ldap_user_object_class = user
ldap_user_home_directory = unixHomeDirectory ldap_user_principal = userPrincipalName
ldap_group_search_base = CN=linuxadmins,DC=int,DC=home,DC=lan ldap_group_object_class = group
#ldap_access_filter = memberOf=cn=linuxadmins,dc=int,dc=home,dc=lan
ldap_access_order = expire ldap_account_expire_policy = ad ldap_force_upper_case_realm = true #ldap_krb5_init_creds = true
# Uncomment if dns discovery of your AD servers isn't working. #krb5_server = 192.168.3.11 krb5_realm = INT.HOME.LAN #krb5_keytab = /etc/krb5.keytab
# Probably required with sssd 1.8.x and newer krb5_canonicalize = false
# Perhaps you need to redirect to certain attributes? #ldap_user_object_class = user #ldap_user_name = sAMAccountName #ldap_user_uid_number = msSFU30UidNumber #ldap_user_gid_number = msSFU30GidNumber #ldap_user_gecos = displayName #ldap_user_home_directory = msSFU30HomeDirectory #ldap_user_shell = msSFU30LoginShell #ldap_user_principal = userPrincipalName #ldap_group_object_class = group #ldap_group_name = cn #ldap_group_gid_number = msSFU30GidNumber
Hi Can you upgrade to a more recent version and use the new ad backend?
If not, remember that the older versions didn't map the ad attributes to something we could recognise. sAMAccountName as being the Linux username is one I remember off the top of my head. Also, don't assume defaults. uncomment the lines until you get it working. We've a 1.9 config against AD here: http://linuxcostablanca.blogspot.com.es/2013/04/sssd-in-samba-40.html HTH Steve
Right, the mappings might need to be adjusted, depending on the environment. The upstream guide for the LDAP provider is here: https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20...
No. That's the guide the OP used for his config. All the AD attrs are commented so the user never gets authenticated.
Unfortuneately im tied to current debian stable in this setup and backporting sssd does not seem possible. Thanx Steve.
On Fri, May 2, 2014 at 10:44 AM, steve steve@steve-ss.com wrote:
On Fri, 2014-05-02 at 10:38 +0200, Jakub Hrozek wrote:
On Fri, May 02, 2014 at 10:32:10AM +0200, steve wrote:
On Fri, 2014-05-02 at 08:47 +0200, Paul Liljenberg wrote:
On Wed, Apr 23, 2014 at 08:10:47AM +0200, Paul Liljenberg wrote:
Notice: I sent this email to the list using another mail address,
which i
believe whas not verified properly. If this emali is properly
sent to the
list you can disregard moderating the message.
Hello
Im setting up a single signon solution for about 1200 servers. The situation as it seems is that we are setting up all users in a
windows 2008
r2 active directory, adding proper unix permissions. A user with
proper
priveliges to read active directory is being used by sssd to read
which
users is allowed in and not. If the users does not have a home
directory
they are being created automatically. So whats the issue here?
Access to
the system does not happen instantanely and i believe its because
sssd is
polling active directory every 120 seconds. It seems as if it has
issues
remaining its state and it is just as if it would loose its local
database.
I would like to be able to have users being logged directly after
a user is
being added to active directory. Is this possible and how could
this be
achieved?
I would encourage you to turn enumeration off. Enumeration is a
background
task that periodically downloads and saves all users from the
server,
which can be very intensitve especially for large environments.
Also, is there a reason to use a bind user and a password and not a keytab and then leverage GSSAPI?
We have some howtos on enrolling a client with AD for pre-1.9
clients:
https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20...
And also for 1.9 and later (recommended): https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server
Ive edit the configuration to not use enumeration. The goal is to use GSSAPI to. For some reason it refuses logins. It does not give me any helpful ouput to fix it.
conf:
[sssd] config_file_version = 2 domains = INT.HOME.LAN services = nss, pam debug_level = 0
[nss] filter_groups = root filter_users = root reconnection_retries = 3
[pam] reconnection_retries = 3
[domain/INT.HOME.LAN] # Unless you know you need referrals, turn them off ldap_referrals = false # Uncomment if you need offline logins cache_credentials = true enumerate = false
id_provider = ldap auth_provider = krb5 chpass_provider = krb5 access_provider = ldap
# Uncomment if service discovery is not working ldap_uri = ldap://vagrant-2008r2.int.home.lan
# Comment out if not using SASL/GSSAPI to bind ldap_sasl_mech = GSSAPI # Uncomment and adjust if the default principal host/fqdn at REALM is not available #ldap_sasl_authid = nfs/client.ad.example.com at AD.EXAMPLE.COM
# Define these only if anonymous binds are not allowed and no keytab is available # Enabling use_start_tls is very important, otherwise the bind password is transmitted # over the network in the clear #ldap_id_use_start_tls = True #ldap_default_bind_dn = CN=test,CN=Users,DC=int,DC=home,DC=local #ldap_default_authtok_type = password #ldap_default_authtok = secretpassword
ldap_schema = rfc2307bis
ldap_user_search_base = CN=Users,DC=int,DC=home,DC=lan ldap_user_object_class = user
ldap_user_home_directory = unixHomeDirectory ldap_user_principal = userPrincipalName
ldap_group_search_base = CN=linuxadmins,DC=int,DC=home,DC=lan ldap_group_object_class = group
#ldap_access_filter = memberOf=cn=linuxadmins,dc=int,dc=home,dc=lan
ldap_access_order = expire ldap_account_expire_policy = ad ldap_force_upper_case_realm = true #ldap_krb5_init_creds = true
# Uncomment if dns discovery of your AD servers isn't working. #krb5_server = 192.168.3.11 krb5_realm = INT.HOME.LAN #krb5_keytab = /etc/krb5.keytab
# Probably required with sssd 1.8.x and newer krb5_canonicalize = false
# Perhaps you need to redirect to certain attributes? #ldap_user_object_class = user #ldap_user_name = sAMAccountName #ldap_user_uid_number = msSFU30UidNumber #ldap_user_gid_number = msSFU30GidNumber #ldap_user_gecos = displayName #ldap_user_home_directory = msSFU30HomeDirectory #ldap_user_shell = msSFU30LoginShell #ldap_user_principal = userPrincipalName #ldap_group_object_class = group #ldap_group_name = cn #ldap_group_gid_number = msSFU30GidNumber
Hi Can you upgrade to a more recent version and use the new ad backend?
If not, remember that the older versions didn't map the ad attributes
to
something we could recognise. sAMAccountName as being the Linux
username
is one I remember off the top of my head. Also, don't assume defaults. uncomment the lines until you get it working. We've a 1.9 config
against
AD here: http://linuxcostablanca.blogspot.com.es/2013/04/sssd-in-samba-40.html HTH Steve
Right, the mappings might need to be adjusted, depending on the environment. The upstream guide for the LDAP provider is here:
https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20...
No. That's the guide the OP used for his config. All the AD attrs are commented so the user never gets authenticated.
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On (02/05/14 11:03), Paul Liljenberg wrote:
Unfortuneately im tied to current debian stable in this setup and backporting sssd does not seem possible. Thanx Steve.
I asked debian maintaner of sssd(Timo). Whether it would be possible to have sssd-1.9.6 in wheezy-backports.
11:09 < lslebodn> tjaalton: Will it be possible to have sssd-1.9 in wheezy (wheezy-backport)? 11:25 < tjaalton> lslebodn: maybe
Paul, you can try to persuade him to do it :-) I added Timo to CC.
LS
On Fri, May 2, 2014 at 10:44 AM, steve steve@steve-ss.com wrote:
On Fri, 2014-05-02 at 10:38 +0200, Jakub Hrozek wrote:
On Fri, May 02, 2014 at 10:32:10AM +0200, steve wrote:
On Fri, 2014-05-02 at 08:47 +0200, Paul Liljenberg wrote:
On Wed, Apr 23, 2014 at 08:10:47AM +0200, Paul Liljenberg wrote: > Notice: I sent this email to the list using another mail address,
which i
> believe whas not verified properly. If this emali is properly
sent to the
> list you can disregard moderating the message. > > Hello > > Im setting up a single signon solution for about 1200 servers. The > situation as it seems is that we are setting up all users in a
windows 2008
> r2 active directory, adding proper unix permissions. A user with
proper
> priveliges to read active directory is being used by sssd to read
which
> users is allowed in and not. If the users does not have a home
directory
> they are being created automatically. So whats the issue here?
Access to
> the system does not happen instantanely and i believe its because
sssd is
> polling active directory every 120 seconds. It seems as if it has
issues
> remaining its state and it is just as if it would loose its local
database.
> I would like to be able to have users being logged directly after
a user is
> being added to active directory. Is this possible and how could
this be
> achieved?
I would encourage you to turn enumeration off. Enumeration is a
background
task that periodically downloads and saves all users from the
server,
which can be very intensitve especially for large environments.
Also, is there a reason to use a bind user and a password and not a keytab and then leverage GSSAPI?
We have some howtos on enrolling a client with AD for pre-1.9
clients:
https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20...
And also for 1.9 and later (recommended): https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server
Ive edit the configuration to not use enumeration. The goal is to use GSSAPI to. For some reason it refuses logins. It does not give me any helpful ouput to fix it.
conf:
[sssd] config_file_version = 2 domains = INT.HOME.LAN services = nss, pam debug_level = 0
[nss] filter_groups = root filter_users = root reconnection_retries = 3
[pam] reconnection_retries = 3
[domain/INT.HOME.LAN] # Unless you know you need referrals, turn them off ldap_referrals = false # Uncomment if you need offline logins cache_credentials = true enumerate = false
id_provider = ldap auth_provider = krb5 chpass_provider = krb5 access_provider = ldap
# Uncomment if service discovery is not working ldap_uri = ldap://vagrant-2008r2.int.home.lan
# Comment out if not using SASL/GSSAPI to bind ldap_sasl_mech = GSSAPI # Uncomment and adjust if the default principal host/fqdn at REALM is not available #ldap_sasl_authid = nfs/client.ad.example.com at AD.EXAMPLE.COM
# Define these only if anonymous binds are not allowed and no keytab is available # Enabling use_start_tls is very important, otherwise the bind password is transmitted # over the network in the clear #ldap_id_use_start_tls = True #ldap_default_bind_dn = CN=test,CN=Users,DC=int,DC=home,DC=local #ldap_default_authtok_type = password #ldap_default_authtok = secretpassword
ldap_schema = rfc2307bis
ldap_user_search_base = CN=Users,DC=int,DC=home,DC=lan ldap_user_object_class = user
ldap_user_home_directory = unixHomeDirectory ldap_user_principal = userPrincipalName
ldap_group_search_base = CN=linuxadmins,DC=int,DC=home,DC=lan ldap_group_object_class = group
#ldap_access_filter = memberOf=cn=linuxadmins,dc=int,dc=home,dc=lan
ldap_access_order = expire ldap_account_expire_policy = ad ldap_force_upper_case_realm = true #ldap_krb5_init_creds = true
# Uncomment if dns discovery of your AD servers isn't working. #krb5_server = 192.168.3.11 krb5_realm = INT.HOME.LAN #krb5_keytab = /etc/krb5.keytab
# Probably required with sssd 1.8.x and newer krb5_canonicalize = false
# Perhaps you need to redirect to certain attributes? #ldap_user_object_class = user #ldap_user_name = sAMAccountName #ldap_user_uid_number = msSFU30UidNumber #ldap_user_gid_number = msSFU30GidNumber #ldap_user_gecos = displayName #ldap_user_home_directory = msSFU30HomeDirectory #ldap_user_shell = msSFU30LoginShell #ldap_user_principal = userPrincipalName #ldap_group_object_class = group #ldap_group_name = cn #ldap_group_gid_number = msSFU30GidNumber
Hi Can you upgrade to a more recent version and use the new ad backend?
If not, remember that the older versions didn't map the ad attributes
to
something we could recognise. sAMAccountName as being the Linux
username
is one I remember off the top of my head. Also, don't assume defaults. uncomment the lines until you get it working. We've a 1.9 config
against
AD here: http://linuxcostablanca.blogspot.com.es/2013/04/sssd-in-samba-40.html HTH Steve
Right, the mappings might need to be adjusted, depending on the environment. The upstream guide for the LDAP provider is here:
https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20...
No. That's the guide the OP used for his config. All the AD attrs are commented so the user never gets authenticated.
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
-- Vänliga Hälsningar / Best Regards Paul Liljenberg
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On 02.05.2014 12:15, Lukas Slebodnik wrote:
On (02/05/14 11:03), Paul Liljenberg wrote:
Unfortuneately im tied to current debian stable in this setup and backporting sssd does not seem possible. Thanx Steve.
I asked debian maintaner of sssd(Timo). Whether it would be possible to have sssd-1.9.6 in wheezy-backports.
11:09 < lslebodn> tjaalton: Will it be possible to have sssd-1.9 in wheezy (wheezy-backport)? 11:25 < tjaalton> lslebodn: maybe
Paul, you can try to persuade him to do it :-) I added Timo to CC.
yes, I'm aware of this request.. have a chroot ready for build tests, trying to figure out which packaging branch to use as the base, since 1.9.x never got in Debian..
On (07/05/14 09:59), Timo Aaltonen wrote:
On 02.05.2014 12:15, Lukas Slebodnik wrote:
On (02/05/14 11:03), Paul Liljenberg wrote:
Unfortuneately im tied to current debian stable in this setup and backporting sssd does not seem possible. Thanx Steve.
I asked debian maintaner of sssd(Timo). Whether it would be possible to have sssd-1.9.6 in wheezy-backports.
11:09 < lslebodn> tjaalton: Will it be possible to have sssd-1.9 in wheezy (wheezy-backport)? 11:25 < tjaalton> lslebodn: maybe
Paul, you can try to persuade him to do it :-) I added Timo to CC.
yes, I'm aware of this request.. have a chroot ready for build tests, trying to figure out which packaging branch to use as the base, since 1.9.x never got in Debian..
1.9 is the last branch which can be build without samba4 (samba-dev) and I was not able to find samba-dev in wheezy https://packages.debian.org/search?suite=wheezy&arch=any&searchon=na...
LS
On 07.05.2014 10:07, Lukas Slebodnik wrote:
On (07/05/14 09:59), Timo Aaltonen wrote:
On 02.05.2014 12:15, Lukas Slebodnik wrote:
On (02/05/14 11:03), Paul Liljenberg wrote:
Unfortuneately im tied to current debian stable in this setup and backporting sssd does not seem possible. Thanx Steve.
I asked debian maintaner of sssd(Timo). Whether it would be possible to have sssd-1.9.6 in wheezy-backports.
11:09 < lslebodn> tjaalton: Will it be possible to have sssd-1.9 in wheezy (wheezy-backport)? 11:25 < tjaalton> lslebodn: maybe
Paul, you can try to persuade him to do it :-) I added Timo to CC.
yes, I'm aware of this request.. have a chroot ready for build tests, trying to figure out which packaging branch to use as the base, since 1.9.x never got in Debian..
1.9 is the last branch which can be build without samba4 (samba-dev) and I was not able to find samba-dev in wheezy https://packages.debian.org/search?suite=wheezy&arch=any&searchon=na...
right, I'll just use the 1.8.x packaging and some fixes cherry-picked
On (07/05/14 10:13), Timo Aaltonen wrote:
On 07.05.2014 10:07, Lukas Slebodnik wrote:
On (07/05/14 09:59), Timo Aaltonen wrote:
On 02.05.2014 12:15, Lukas Slebodnik wrote:
On (02/05/14 11:03), Paul Liljenberg wrote:
Unfortuneately im tied to current debian stable in this setup and backporting sssd does not seem possible. Thanx Steve.
I asked debian maintaner of sssd(Timo). Whether it would be possible to have sssd-1.9.6 in wheezy-backports.
11:09 < lslebodn> tjaalton: Will it be possible to have sssd-1.9 in wheezy (wheezy-backport)? 11:25 < tjaalton> lslebodn: maybe
Paul, you can try to persuade him to do it :-) I added Timo to CC.
yes, I'm aware of this request.. have a chroot ready for build tests, trying to figure out which packaging branch to use as the base, since 1.9.x never got in Debian..
1.9 is the last branch which can be build without samba4 (samba-dev) and I was not able to find samba-dev in wheezy https://packages.debian.org/search?suite=wheezy&arch=any&searchon=na...
right, I'll just use the 1.8.x packaging and some fixes cherry-picked
If you want I have a "Work in progres patch" which disable ipa and ad provider in 1.11 branch and thus 1.11 branch can be compiled without samba4
LS
hm in the last working setup i used 1.11 branch with the ad provider. To be sure successful signon works it would be nice to have some reference config that we know works with that branch. ( https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server) Ive only seen this for the ad provider. Do we need samba-dev to build the adprovider for 1.9 branch aswell?
On Wed, May 7, 2014 at 9:20 AM, Lukas Slebodnik lslebodn@redhat.com wrote:
On (07/05/14 10:13), Timo Aaltonen wrote:
On 07.05.2014 10:07, Lukas Slebodnik wrote:
On (07/05/14 09:59), Timo Aaltonen wrote:
On 02.05.2014 12:15, Lukas Slebodnik wrote:
On (02/05/14 11:03), Paul Liljenberg wrote:
Unfortuneately im tied to current debian stable in this setup and backporting sssd does not seem possible. Thanx Steve.
I asked debian maintaner of sssd(Timo). Whether it would be possible
to
have sssd-1.9.6 in wheezy-backports.
11:09 < lslebodn> tjaalton: Will it be possible to have sssd-1.9 in
wheezy
(wheezy-backport)? 11:25 < tjaalton> lslebodn: maybe
Paul, you can try to persuade him to do it :-) I added Timo to CC.
yes, I'm aware of this request.. have a chroot ready for build tests, trying to figure out which packaging branch to use as the base, since 1.9.x never got in Debian..
1.9 is the last branch which can be build without samba4 (samba-dev) and I was not able to find samba-dev in wheezy
https://packages.debian.org/search?suite=wheezy&arch=any&searchon=na...
right, I'll just use the 1.8.x packaging and some fixes cherry-picked
If you want I have a "Work in progres patch" which disable ipa and ad provider in 1.11 branch and thus 1.11 branch can be compiled without samba4
LS _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On (07/05/14 09:29), Paul Liljenberg wrote:
hm in the last working setup i used 1.11 branch with the ad provider. To be sure successful signon works it would be nice to have some reference config that we know works with that branch. ( https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server) Ive only seen this for the ad provider. Do we need samba-dev to build the adprovider for 1.9 branch aswell?
The 1.9 branch has ad provider, but there isn't strict dependency on samba-dev. Of course, there are not all features from 1.11 branch.
I could not find in source code why samba is optional in 1.9 branch. Someone else should explain this.
LS
On Wed, May 07, 2014 at 09:50:39AM +0200, Lukas Slebodnik wrote:
On (07/05/14 09:29), Paul Liljenberg wrote:
hm in the last working setup i used 1.11 branch with the ad provider. To be sure successful signon works it would be nice to have some reference config that we know works with that branch. ( https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server) Ive only seen this for the ad provider. Do we need samba-dev to build the adprovider for 1.9 branch aswell?
The 1.9 branch has ad provider, but there isn't strict dependency on samba-dev. Of course, there are not all features from 1.11 branch.
I could not find in source code why samba is optional in 1.9 branch. Someone else should explain this.
LS
According to a bit of git digging, the unconditional samba4-libs dependency was added when site discovery support was implemented.
I'm not sure if you're talking about a proper Debian/Ubuntu backport or some kind of PPA, but wouldn't it be easiest for a PPA to not package the AD back end at all and only package the LDAP provider? The current 1.8 users are using LDAP only anyway..
On (07/05/14 10:37), Jakub Hrozek wrote:
On Wed, May 07, 2014 at 09:50:39AM +0200, Lukas Slebodnik wrote:
On (07/05/14 09:29), Paul Liljenberg wrote:
hm in the last working setup i used 1.11 branch with the ad provider. To be sure successful signon works it would be nice to have some reference config that we know works with that branch. ( https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server) Ive only seen this for the ad provider. Do we need samba-dev to build the adprovider for 1.9 branch aswell?
The 1.9 branch has ad provider, but there isn't strict dependency on samba-dev. Of course, there are not all features from 1.11 branch.
I could not find in source code why samba is optional in 1.9 branch. Someone else should explain this.
LS
According to a bit of git digging, the unconditional samba4-libs dependency was added when site discovery support was implemented.
I'm not sure if you're talking about a proper Debian/Ubuntu backport or some kind of PPA, but wouldn't it be easiest for a PPA to not package the AD back end at all and only package the LDAP provider? The current 1.8 users are using LDAP only anyway..
If you want to pacakge 1.11 branch on debian stable you will need to build it. If you want to build 1.11 branch on debian stable you will need to install samba4 develompment header files. samba-dev is not available on debian stable.
LS
If the sssd package is able to be installed via an apt repo in /etc/apt/sources.list we are able to use it. It doesnt matter if its located in ppa as long as debian stable can install from it.
On Wed, May 7, 2014 at 10:43 AM, Lukas Slebodnik lslebodn@redhat.comwrote:
On (07/05/14 10:37), Jakub Hrozek wrote:
On Wed, May 07, 2014 at 09:50:39AM +0200, Lukas Slebodnik wrote:
On (07/05/14 09:29), Paul Liljenberg wrote:
hm in the last working setup i used 1.11 branch with the ad provider.
To be
sure successful signon works it would be nice to have some reference
config
that we know works with that branch. ( https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server)
Ive
only seen this for the ad provider. Do we need samba-dev to build the adprovider for 1.9 branch aswell?
The 1.9 branch has ad provider, but there isn't strict dependency on
samba-dev.
Of course, there are not all features from 1.11 branch.
I could not find in source code why samba is optional in 1.9 branch. Someone else should explain this.
LS
According to a bit of git digging, the unconditional samba4-libs dependency was added when site discovery support was implemented.
I'm not sure if you're talking about a proper Debian/Ubuntu backport or some kind of PPA, but wouldn't it be easiest for a PPA to not package the AD back end at all and only package the LDAP provider? The current 1.8 users are using LDAP only anyway..
If you want to pacakge 1.11 branch on debian stable you will need to build it. If you want to build 1.11 branch on debian stable you will need to install samba4 develompment header files. samba-dev is not available on debian stable.
LS _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Is there any status updates on the backport for ssd?
On Wed, May 7, 2014 at 11:18 AM, Paul Liljenberg liljenberg.paul@gmail.comwrote:
If the sssd package is able to be installed via an apt repo in /etc/apt/sources.list we are able to use it. It doesnt matter if its located in ppa as long as debian stable can install from it.
On Wed, May 7, 2014 at 10:43 AM, Lukas Slebodnik lslebodn@redhat.comwrote:
On (07/05/14 10:37), Jakub Hrozek wrote:
On Wed, May 07, 2014 at 09:50:39AM +0200, Lukas Slebodnik wrote:
On (07/05/14 09:29), Paul Liljenberg wrote:
hm in the last working setup i used 1.11 branch with the ad provider.
To be
sure successful signon works it would be nice to have some reference
config
that we know works with that branch. ( https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server)
Ive
only seen this for the ad provider. Do we need samba-dev to build the adprovider for 1.9 branch aswell?
The 1.9 branch has ad provider, but there isn't strict dependency on
samba-dev.
Of course, there are not all features from 1.11 branch.
I could not find in source code why samba is optional in 1.9 branch. Someone else should explain this.
LS
According to a bit of git digging, the unconditional samba4-libs dependency was added when site discovery support was implemented.
I'm not sure if you're talking about a proper Debian/Ubuntu backport or some kind of PPA, but wouldn't it be easiest for a PPA to not package the AD back end at all and only package the LDAP provider? The current 1.8 users are using LDAP only anyway..
If you want to pacakge 1.11 branch on debian stable you will need to build it. If you want to build 1.11 branch on debian stable you will need to install samba4 develompment header files. samba-dev is not available on debian stable.
LS _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
-- Vänliga Hälsningar / Best Regards Paul Liljenberg
On Mon, May 12, 2014 at 01:37:45PM +0200, Paul Liljenberg wrote:
Is there any status updates on the backport for ssd?
Lukas sent a patch to sssd-devel to make the samba4 dependency optional: https://lists.fedorahosted.org/pipermail/sssd-devel/2014-May/019449.html
I haven't had a chance to test it yet..it would be very helpful if you could do some testing if possible.
Ok, i can see the patches. It cant figure out which one is for master and which is for 1.11 branch. It sais 1.9 on the bottom of the patch messages.
On Mon, May 12, 2014 at 1:37 PM, Paul Liljenberg liljenberg.paul@gmail.comwrote:
Is there any status updates on the backport for ssd?
On Wed, May 7, 2014 at 11:18 AM, Paul Liljenberg < liljenberg.paul@gmail.com> wrote:
If the sssd package is able to be installed via an apt repo in /etc/apt/sources.list we are able to use it. It doesnt matter if its located in ppa as long as debian stable can install from it.
On Wed, May 7, 2014 at 10:43 AM, Lukas Slebodnik lslebodn@redhat.comwrote:
On (07/05/14 10:37), Jakub Hrozek wrote:
On Wed, May 07, 2014 at 09:50:39AM +0200, Lukas Slebodnik wrote:
On (07/05/14 09:29), Paul Liljenberg wrote:
hm in the last working setup i used 1.11 branch with the ad
provider. To be
sure successful signon works it would be nice to have some reference
config
that we know works with that branch. ( https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server)
Ive
only seen this for the ad provider. Do we need samba-dev to build the adprovider for 1.9 branch aswell?
The 1.9 branch has ad provider, but there isn't strict dependency on
samba-dev.
Of course, there are not all features from 1.11 branch.
I could not find in source code why samba is optional in 1.9 branch. Someone else should explain this.
LS
According to a bit of git digging, the unconditional samba4-libs dependency was added when site discovery support was implemented.
I'm not sure if you're talking about a proper Debian/Ubuntu backport or some kind of PPA, but wouldn't it be easiest for a PPA to not package the AD back end at all and only package the LDAP provider? The current 1.8 users are using LDAP only anyway..
If you want to pacakge 1.11 branch on debian stable you will need to build it. If you want to build 1.11 branch on debian stable you will need to install samba4 develompment header files. samba-dev is not available on debian stable.
LS _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
-- Vänliga Hälsningar / Best Regards Paul Liljenberg
-- Vänliga Hälsningar / Best Regards Paul Liljenberg
On Tue, May 13, 2014 at 08:46:05AM +0200, Paul Liljenberg wrote:
Ok, i can see the patches. It cant figure out which one is for master and which is for 1.11 branch. It sais 1.9 on the bottom of the patch messages.
There are two patches in the thread, one is for master and one is for sssd-1-11.
Yes, is the last patch in the mail for 1.11 branch?
On Tue, May 13, 2014 at 9:31 AM, Jakub Hrozek jhrozek@redhat.com wrote:
On Tue, May 13, 2014 at 08:46:05AM +0200, Paul Liljenberg wrote:
Ok, i can see the patches. It cant figure out which one is for master and which is for 1.11 branch. It sais 1.9 on the bottom of the patch
messages.
There are two patches in the thread, one is for master and one is for sssd-1-11. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Tue, May 13, 2014 at 09:41:31AM +0200, Paul Liljenberg wrote:
Yes, is the last patch in the mail for 1.11 branch?
The one called '0001-sssd-1-11-BUILD-Make-samba4-libraries-optional.patch' is supposed to apply cleanly on sssd-1-11.
On (13/05/14 08:46), Paul Liljenberg wrote:
Ok, i can see the patches. It cant figure out which one is for master and which is for 1.11 branch. It sais 1.9 on the bottom of the patch messages.
1.9 on the bottom is the version of git which was used for generating a patch.
$git --version git version 1.9.0
LS
Sorry, i don't understand how to use these pathes. It seem as if there is two patches pointing to 1.9. They seem to reference the same files. For what i can understand these two patches are for master and 1.11 branch. Is it just so easy that the patch has been generated within two different timeframes and both should be applied to 1.9 branch?
On (13/05/14 14:05), Paul Liljenberg wrote:
Sorry, i don't understand how to use these pathes. It seem as if there is two patches pointing to 1.9. They seem to reference the same files. For what i can understand these two patches are for master and 1.11 branch. Is it just so easy that the patch has been generated within two different timeframes and both should be applied to 1.9 branch?
I am attaching patch for 1-11 branch for you. The name of attachment is 0001-sssd-1-11-BUILD-Make-samba4-libraries-optional.patch
If you need to instructions about applying patch and building sssd feel free to contact me privately.
LS
The patch from Lukas did succeed very well on 1.11.5.1 . You need to have autotools installed to properly regenerate ./configure file. This is done by "autoreconf -if" before running configure. I have tested the compiled binary and that works. What needs to be done now is to build a proper debian package for this.I would try to use the package from testing and replace the libs and binaries. If theres a more Debian way please tell. Timo, do you have time for building this? I also want to thank Lucas for taking his time building a patch som it would be possible to have 1.11.5.1 in Debian stable without samba4-devel. Hopefully this would solve any issues related to active directory that i mentioned previous.
On Tue, May 13, 2014 at 2:44 PM, Lukas Slebodnik lslebodn@redhat.comwrote:
On (13/05/14 14:05), Paul Liljenberg wrote:
Sorry, i don't understand how to use these pathes. It seem as if there is two patches pointing to 1.9. They seem to reference the same files. For what i can understand these two patches are for master and 1.11
branch.
Is it just so easy that the patch has been generated within two different timeframes and both should be applied to 1.9 branch?
I am attaching patch for 1-11 branch for you. The name of attachment is 0001-sssd-1-11-BUILD-Make-samba4-libraries-optional.patch
If you need to instructions about applying patch and building sssd feel free to contact me privately.
LS
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On (14/05/14 08:20), Paul Liljenberg wrote:
The patch from Lukas did succeed very well on 1.11.5.1 . You need to have autotools installed to properly regenerate ./configure file. This is done by "autoreconf -if" before running configure. I have tested the compiled binary and that works. What needs to be done now is to build a proper debian package for this.I would try to use the package from testing and replace the libs and binaries.
It is very likely that you will not be able to use the sssd package from debian testing. There will be strict dependency on newer version of libraries. It is not related to packaging but how linking of binaries works. You will need to install libraries from testing as well. As a result of this you will upgrade half of your system to debian testing. e.g. libkrb5 ...
I think you have two options: * use your own sssd built from tarball + extra patch * wait for official sssd-1.11 in wheezy-backports
If theres a more Debian way please tell. Timo, do you have time for building this? I also want to thank Lucas for taking his time building a patch som it would be possible to have 1.11.5.1 in Debian stable without samba4-devel. Hopefully this would solve any issues related to active directory that i mentioned previous.
LS
Replacing the binaries and libs was no issues in itself, The issue is that it could not find the libs and even if i specifically pointed to the libdir while configureing ie ./configure --without-samba --libdir=/usr/lib/x86_64-linux-gnu/sssd it still resulted in the following issues.
root@client:~# dpkg -i test.deb (Reading database ... 72929 files and directories currently installed.) Preparing to replace sssd 1.8.4-2 (using test.deb) ... Unpacking replacement sssd ... Setting up sssd (1.8.4-2) ... /usr/sbin/sssd: error while loading shared libraries: libsss_util.so: cannot open shared object file: No such file or directory [FAIL] Starting System Security Services Daemon: sssd failed! Processing triggers for man-db ...
root@client:~/sssd-1.11.5.1# ldd /usr/sbin/sssd linux-vdso.so.1 => (0x00007fff9a1ff000) libtevent.so.0 => /usr/lib/x86_64-linux-gnu/libtevent.so.0 (0x00007fa5d4c2e000) libtalloc.so.2 => /usr/lib/x86_64-linux-gnu/libtalloc.so.2 (0x00007fa5d4a23000) libpopt.so.0 => /lib/x86_64-linux-gnu/libpopt.so.0 (0x00007fa5d4815000) libldb.so.1 => /usr/lib/x86_64-linux-gnu/libldb.so.1 (0x00007fa5d45e0000) libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3 (0x00007fa5d439a000) libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fa5d415c000) libini_config.so.2 => /usr/lib/x86_64-linux-gnu/libini_config.so.2 (0x00007fa5d3f53000) libcollection.so.2 => /usr/lib/x86_64-linux-gnu/libcollection.so.2 (0x00007fa5d3d47000) libdhash.so.1 => /usr/lib/x86_64-linux-gnu/libdhash.so.1 (0x00007fa5d3b42000) libnss3.so => /usr/lib/x86_64-linux-gnu/libnss3.so (0x00007fa5d3804000) libnssutil3.so => /usr/lib/x86_64-linux-gnu/libnssutil3.so (0x00007fa5d35d8000) libsmime3.so => /usr/lib/x86_64-linux-gnu/libsmime3.so (0x00007fa5d33aa000) libssl3.so => /usr/lib/x86_64-linux-gnu/libssl3.so (0x00007fa5d3165000) libplds4.so => /usr/lib/x86_64-linux-gnu/libplds4.so (0x00007fa5d2f61000) libplc4.so => /usr/lib/x86_64-linux-gnu/libplc4.so (0x00007fa5d2d5b000) libnspr4.so => /usr/lib/x86_64-linux-gnu/libnspr4.so (0x00007fa5d2b1b000) liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 (0x00007fa5d290c000) libldap_r-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 (0x00007fa5d26ba000) libtdb.so.1 => /usr/lib/x86_64-linux-gnu/libtdb.so.1 (0x00007fa5d24a9000) libsss_util.so => not found libsss_crypt.so => not found libsss_debug.so => not found libsss_child.so => not found libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fa5d22a3000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa5d1f18000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fa5d1cfc000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fa5d1af3000) libpath_utils.so.1 => /usr/lib/x86_64-linux-gnu/libpath_utils.so.1 (0x00007fa5d18ef000) libref_array.so.1 => /usr/lib/x86_64-linux-gnu/libref_array.so.1 (0x00007fa5d16ec000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fa5d14d4000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007fa5d12be000) libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007fa5d10a2000) libgnutls.so.26 => /usr/lib/x86_64-linux-gnu/libgnutls.so.26 (0x00007fa5d0de2000) libgcrypt.so.11 => /lib/x86_64-linux-gnu/libgcrypt.so.11 (0x00007fa5d0b64000) libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007fa5d092c000) /lib64/ld-linux-x86-64.so.2 (0x00007fa5d4e46000) libtasn1.so.3 => /usr/lib/x86_64-linux-gnu/libtasn1.so.3 (0x00007fa5d071b000) libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007fa5d0508000) libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007fa5d0305000)
Note that the modules was located in the following folder.
root@client:~# ls /usr/lib/x86_64-linux-gnu/sssd/ libsss_ipa.so libsss_krb5.so libsss_ldap.so libsss_proxy.so libsss_simple.so libsss_util.so modules
On Wed, May 14, 2014 at 8:57 AM, Lukas Slebodnik lslebodn@redhat.comwrote:
On (14/05/14 08:20), Paul Liljenberg wrote:
The patch from Lukas did succeed very well on 1.11.5.1 . You need to have autotools installed to properly regenerate ./configure file. This is done by "autoreconf -if" before running configure. I have tested the compiled binary and that
works.
What needs to be done now is to build a proper debian package for this.I would try to use the package from testing and replace the libs and binaries.
It is very likely that you will not be able to use the sssd package from debian testing. There will be strict dependency on newer version of libraries. It is not related to packaging but how linking of binaries works. You will need to install libraries from testing as well. As a result of this you will upgrade half of your system to debian testing. e.g. libkrb5 ...
I think you have two options: * use your own sssd built from tarball + extra patch * wait for official sssd-1.11 in wheezy-backports
If theres a more Debian way please tell. Timo, do you have time for building this? I also want to thank Lucas for taking his time building a patch som it would be possible to have 1.11.5.1 in Debian stable without samba4-devel. Hopefully this would solve any issues related to active directory that i mentioned previous.
LS _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Wed, May 07, 2014 at 10:43:47AM +0200, Lukas Slebodnik wrote:
On (07/05/14 10:37), Jakub Hrozek wrote:
On Wed, May 07, 2014 at 09:50:39AM +0200, Lukas Slebodnik wrote:
On (07/05/14 09:29), Paul Liljenberg wrote:
hm in the last working setup i used 1.11 branch with the ad provider. To be sure successful signon works it would be nice to have some reference config that we know works with that branch. ( https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server) Ive only seen this for the ad provider. Do we need samba-dev to build the adprovider for 1.9 branch aswell?
The 1.9 branch has ad provider, but there isn't strict dependency on samba-dev. Of course, there are not all features from 1.11 branch.
I could not find in source code why samba is optional in 1.9 branch. Someone else should explain this.
LS
According to a bit of git digging, the unconditional samba4-libs dependency was added when site discovery support was implemented.
I'm not sure if you're talking about a proper Debian/Ubuntu backport or some kind of PPA, but wouldn't it be easiest for a PPA to not package the AD back end at all and only package the LDAP provider? The current 1.8 users are using LDAP only anyway..
If you want to pacakge 1.11 branch on debian stable you will need to build it. If you want to build 1.11 branch on debian stable you will need to install samba4 develompment header files. samba-dev is not available on debian stable.
Right, I was thinking of having a build-time only samba4 package as well..but if that's not an option, then I guess you'd have to patch the Makefile to not build the sssd-ad provider at all..
The reason not to use 1.11 branch is that libc is a higher version as a dependency than the one debian 7.5 has wich means that building would break anything else. I have only successfully compiled sssd 1.9 branch for debian stable. I would be nice to have 1.11 branch working but i believe we are trying to stretch things to far.
On Wed, May 7, 2014 at 8:59 AM, Timo Aaltonen tjaalton@ubuntu.com wrote:
On 02.05.2014 12:15, Lukas Slebodnik wrote:
On (02/05/14 11:03), Paul Liljenberg wrote:
Unfortuneately im tied to current debian stable in this setup and backporting sssd does not seem possible. Thanx Steve.
I asked debian maintaner of sssd(Timo). Whether it would be possible to have sssd-1.9.6 in wheezy-backports.
11:09 < lslebodn> tjaalton: Will it be possible to have sssd-1.9 in
wheezy
(wheezy-backport)? 11:25 < tjaalton> lslebodn: maybe
Paul, you can try to persuade him to do it :-) I added Timo to CC.
yes, I'm aware of this request.. have a chroot ready for build tests, trying to figure out which packaging branch to use as the base, since 1.9.x never got in Debian..
-- t _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Fri, 2014-05-02 at 11:03 +0200, Paul Liljenberg wrote:
Unfortuneately im tied to current debian stable in this setup and backporting sssd does not seem possible. Thanx Steve.
OK. You'll have to do the AD attribute mapping manually then. This worked for us with 1.9:
ldap_user_object_class = user ldap_user_name = samAccountName ldap_user_uid_number = uidNumber ldap_user_gid_number = gidNumber ldap_user_home_directory = unixHomeDirectory ldap_user_shell = loginShell ldap_group_object_class = group ldap_group_search_base = dc=your,dc=domain ldap_group_name = cn ldap_group_member = member #ldap_user_search_filter =(&(objectCategory=User)(uidNumber=*))
I think the commented filter was for 1.8. This should get your user through the process. HTH Steve
I did try modifying the conf with your suggested settings, but it did not work. Hm.. I wonder if theres an error with sasl.
/var/log/auth.log: May 2 12:58:44 client sssd_be: canonuserfunc error -7 May 2 12:58:44 client sssd_be: _sasl_plugin_load failed on sasl_canonuser_init for plugin: ldapdb
What do you think?
On Fri, May 2, 2014 at 11:22 AM, steve steve@steve-ss.com wrote:
On Fri, 2014-05-02 at 11:03 +0200, Paul Liljenberg wrote:
Unfortuneately im tied to current debian stable in this setup and backporting sssd does not seem possible. Thanx Steve.
OK. You'll have to do the AD attribute mapping manually then. This worked for us with 1.9:
ldap_user_object_class = user ldap_user_name = samAccountName ldap_user_uid_number = uidNumber ldap_user_gid_number = gidNumber ldap_user_home_directory = unixHomeDirectory ldap_user_shell = loginShell ldap_group_object_class = group ldap_group_search_base = dc=your,dc=domain ldap_group_name = cn ldap_group_member = member #ldap_user_search_filter =(&(objectCategory=User)(uidNumber=*))
I think the commented filter was for 1.8. This should get your user through the process. HTH Steve
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Fri, 2014-05-02 at 13:21 +0200, Paul Liljenberg wrote:
I did try modifying the conf with your suggested settings, but it did not work. Hm.. I wonder if theres an error with sasl.
/var/log/auth.log: May 2 12:58:44 client sssd_be: canonuserfunc error -7 May 2 12:58:44 client sssd_be: _sasl_plugin_load failed on sasl_canonuser_init for plugin: ldapdb
What do you think?
Do you have the time or are allowed to build a later version? Guessing what the devs have posted, it looks as if debian is stuck with an old version. I know gssapi works with 1.9 and better with the link I posted. Oh, maybe check the key really is in the keytab?
Cheers, Steve
On Fri, May 2, 2014 at 11:22 AM, steve steve@steve-ss.com wrote: On Fri, 2014-05-02 at 11:03 +0200, Paul Liljenberg wrote: > Unfortuneately im tied to current debian stable in this setup and > backporting sssd does not seem possible. Thanx Steve. >
OK. You'll have to do the AD attribute mapping manually then. This worked for us with 1.9: ldap_user_object_class = user ldap_user_name = samAccountName ldap_user_uid_number = uidNumber ldap_user_gid_number = gidNumber ldap_user_home_directory = unixHomeDirectory ldap_user_shell = loginShell ldap_group_object_class = group ldap_group_search_base = dc=your,dc=domain ldap_group_name = cn ldap_group_member = member #ldap_user_search_filter =(&(objectCategory=User)(uidNumber=*)) I think the commented filter was for 1.8. This should get your user through the process. HTH Steve _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users-- Vänliga Hälsningar / Best Regards Paul Liljenberg _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
I have the time to build and yes current 1.9 builds fine on debian stable. I could build a debian package with fpm but it would be nice to have it in backports.
On Fri, May 2, 2014 at 2:52 PM, steve steve@steve-ss.com wrote:
On Fri, 2014-05-02 at 13:21 +0200, Paul Liljenberg wrote:
I did try modifying the conf with your suggested settings, but it did not work. Hm.. I wonder if theres an error with sasl.
/var/log/auth.log: May 2 12:58:44 client sssd_be: canonuserfunc error -7 May 2 12:58:44 client sssd_be: _sasl_plugin_load failed on sasl_canonuser_init for plugin: ldapdb
What do you think?
Do you have the time or are allowed to build a later version? Guessing what the devs have posted, it looks as if debian is stuck with an old version. I know gssapi works with 1.9 and better with the link I posted. Oh, maybe check the key really is in the keytab?
Cheers, Steve
On Fri, May 2, 2014 at 11:22 AM, steve steve@steve-ss.com wrote: On Fri, 2014-05-02 at 11:03 +0200, Paul Liljenberg wrote: > Unfortuneately im tied to current debian stable in this setup and > backporting sssd does not seem possible. Thanx Steve. >
OK. You'll have to do the AD attribute mapping manually then. This worked for us with 1.9: ldap_user_object_class = user ldap_user_name = samAccountName ldap_user_uid_number = uidNumber ldap_user_gid_number = gidNumber ldap_user_home_directory = unixHomeDirectory ldap_user_shell = loginShell ldap_group_object_class = group ldap_group_search_base = dc=your,dc=domain ldap_group_name = cn ldap_group_member = member #ldap_user_search_filter =(&(objectCategory=User)(uidNumber=*)) I think the commented filter was for 1.8. This should get your user through the process. HTH Steve _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users-- Vänliga Hälsningar / Best Regards Paul Liljenberg _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
sssd-users@lists.fedorahosted.org
-
Jakub Hrozek -
Lukas Slebodnik -
Paul Liljenberg -
steve -
Timo Aaltonen