[PATCH] Providers cleanup: Remove unused parameters
by Jakub Hrozek
During the nested initgroups processing review, Jan requested removing
unused "dom" parameter from the code. Instead of doing it on that one
place, I compiled SSSD with -Wunused and cleaned up unused parameters in
the providers code. It's mostly sss_domain_info no longer needed because
of the sysdb refactoring.
The patch brings no functional change, it's just cleanup.
12 years, 5 months
LDAPS Connection error
by sssd help
Hi List,
Any help here would be appreciated.
We've been using SSSD (1.2) on RHEL6 for a while without issue. We are
trying to make the move to RHEL6.1 and newer packages of SSSD (1.5.1) and
we are running into some problems.
For some reason the client doesnt seem to want to connect to our ldap
server using LDAPS. See the following log output:
(Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [sdap_id_op_connect_step]
(9): beginning to connect
(Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [fo_resolve_service_send]
(4): Trying to resolve service 'LDAP'
(Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [get_server_status] (7):
Status of server 'ldap.example.com' is 'name not resolved'
(Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [get_server_status] (4):
Hostname resolution expired, reseting the server status of 'ldap.example.com
'
(Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [set_server_common_status]
(4): Marking server 'ldap.example.com' as 'name not resolved'
(Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [get_port_status] (7): Port
status of port 636 for server 'ldap.example.com' is 'neutral'
(Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [get_server_status] (7):
Status of server 'ldap.example.com' is 'name not resolved'
(Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [resolv_gethostbyname_send]
(4): Trying to resolve A record of 'ldap.example.com'
(Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [schedule_timeout_watcher]
(9): Scheduling DNS timeout watcher
(Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [set_server_common_status]
(4): Marking server 'ldap.example.com' as 'resolving name'
(Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [unschedule_timeout_watcher]
(9): Unscheduling DNS timeout watcher
(Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [set_server_common_status]
(4): Marking server 'ldap.example.com' as 'name resolved'
(Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [be_resolve_server_done]
(4): Found address for server ldap.example.com: [10.17.8.103]
(Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [sdap_uri_callback] (6):
Constructed uri 'ldaps://ldap.example.com/'
(Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [sdap_get_rootdse_send] (9):
Getting rootdse
(Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [sdap_get_generic_send] (6):
calling ldap_search_ext with [(objectclass=*)][].
(Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [sdap_get_generic_send] (7):
Requesting attrs: [*]
(Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [sdap_get_generic_send] (7):
Requesting attrs: [altServer]
(Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [sdap_get_generic_send] (7):
Requesting attrs: [namingContexts]
(Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [sdap_get_generic_send] (7):
Requesting attrs: [supportedControl]
(Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [sdap_get_generic_send] (7):
Requesting attrs: [supportedExtension]
(Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [sdap_get_generic_send] (7):
Requesting attrs: [supportedFeatures]
(Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [sdap_get_generic_send] (7):
Requesting attrs: [supportedLDAPVersion]
(Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [sdap_get_generic_send] (7):
Requesting attrs: [supportedSASLMechanisms]
(Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [sdap_get_generic_send] (7):
Requesting attrs: [defaultNamingContext]
(Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [sdap_get_generic_send] (7):
Requesting attrs: [lastUSN]
(Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [sdap_get_generic_send] (7):
Requesting attrs: [highestCommittedUSN]
(Mon Nov 21 17:07:58 2011) [sssd[be[default]]]
[sdap_ldap_connect_callback_add] (9): New LDAP connection to [ldaps://
ldap.example.com:636] with fd [25].
(Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [sdap_get_generic_send] (3):
ldap_search_ext failed: Can't contact LDAP server
(Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [sdap_get_generic_send] (3):
Connection error: (null)
(Mon Nov 21 17:07:58 2011) [sssd[be[default]]] [fo_set_port_status] (4):
Marking port 636 of server 'ldap.example.com' as 'not working'
Please also see the following sssd.conf:
[sssd]
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam
#services = pam
domains = default
[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3
[pam]
reconnection_retries = 3
[domain/default]
ldap_tls_reqcert = never
auth_provider = ldap
ldap_id_use_start_tls = False
chpass_provider = ldap
enumerate = True
cache_credentials = True
ldap_group_search_base = ou=posixGroups,dc=example,dc=com
ldap_user_search_base = ou=People,dc=example,dc=com
ldap_default_authtok_type = password
ldap_search_base = dc=example,dc=com
debug_level = 20
id_provider = ldap
ldap_default_bind_dn = uid=binduser,ou=Special Users,dc=example,dc=com
ldap_user_gecos = cn
ldap_uri = ldaps://ldap.example.com/
ldap_default_authtok = password
ldap_tls_cacertdir = /etc/ssl/certs
This is the very same config we use on RHEL6 with sssd 1.2. I also tried
porting the older sssd build onto this machine and got the same results.
Please note that TLS is not an option in our case because we are performing
an ssl offload on a hardware load balancer that cannot handle TLS.
This mailing list has been extremely helpful in the past and i hope it is
so again. Thank you
Brandon
12 years, 5 months
SSSD (another) wish-list
by Ondrej Valousek
Hi list,
Currently, we are using Centrify for Linux&AD integration so I was thinking we could soon save some $$$ and use sssd for the same purpose.
There is still one thing (among others to which a RFEs have already been submitted) I am missing:
Would it be possible for sssd to maintain the OperatingSystem attribute in AD updated? I know that IPA uses quite minimalistic LDAP schema
so it is pity that it does not have any such an attribute, but if it had (comments needed), the same code could be used for IPA and AD domains.
I am asking for auditing purposes - currently with Centrify it is easy to query AD just for OperatingSystem attribute and one can
immediately see which OSes have been installed in the company.
Many thanks,
Ondrej
12 years, 5 months
sssd can't get shadow information from ldap
by Aziz Sasmaz
Hi,
sssd can't get shadow info from ldap. When I type getent passwd it shows
pass section as * not as "x"
As passwd (5) ; If the encrypted password is set to an asterisk, the user
will be unable to login using login.
Can sssd get shadow information from ldap. Is it possible to cache
authentication when we use ldap/shadow ?
nlastname1:*:1094:1004:Name Lastname:/home/user1:/bin/bash
nlastname2:*:1025:501:otemli:/home/user2:/bin/sh
nlastname3:*:1040:1009:Name Lastname:/home/user3:/bin/bash
splunk:*:1116:1025:Splunk Server:/opt/splunkforwarder:/bin/bash
my sssd.conf file:
[sssd]
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam
domains = ldap.jazzythemartian.com
[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3
[pam]
[domain/ldap.jazzythemartian.com]
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
access_provider = ldap
ldap_schema = rfc2307
ldap_uri = ldaps://ldaptest.jazzythemartian.com
ldap_search_base = dc=jazzythemartian,dc=com
ldap_tls_reqcert = allow
cache_credentials = true
enumerate = true
entry_cache_timeout = 5400
ldap_pwd_policy = shadow
ldap_user_gecos = uid
My system-auth file:
auth required pam_env.so
auth sufficient pam_sss.so use_first_pass
auth sufficient pam_ldap.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth required pam_deny.so
account required pam_unix.so
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account sufficient pam_ldap.so
account sufficient pam_succeed_if.so uid < 500 quiet
account required pam_permit.so
#password requisite pam_cracklib.so try_first_pass retry=3
password required pam_passwdqc.so enforce=users
min=disabled,16,12,8,6
password sufficient pam_sss.so use_authtok
password sufficient pam_ldap.so use_authtok
password sufficient pam_unix.so md5 shadow nullok try_first_pass
use_authtok
password required pam_deny.so
session optional pam_mkhomedir.so skel=/etc/skel/ umask=0022
session optional pam_keyinit.so revoke
session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in crond
quiet use_uid
session sufficient pam_sss.so
session required pam_unix.so
session sufficient pam_ldap.so
Thanks,
AS
12 years, 5 months
