sssd incorrectly claims duplicate GIDs found
by Jeff White
I am running 80+ CentOS 7 systems all configured identically. I found
one of my groups is not working on several of them. sssd's log shows:
Aug 18 08:25:07 cn33 sssd[nss][3804]: More groups have the same GID
[7021] in directory server. SSSD will not work correctly.
sssd is configured to query Active Directory so I ran an query for
'gidNumber=7021' via ldapsearch. That returned only one result. 7021
is also not in /etc/group. I have not been able to find any useful
information in sssd's other logs (nor do I know what each log is, so I'm
just digging blindly):
# ls -lh /var/log/sssd/
total 75M
-rw------- 1 root root 0 Aug 16 03:42 krb5_child.log
-rw------- 1 root root 5.4K Aug 18 08:10 krb5_child.log-20160816
-rw------- 1 root root 3.5K Aug 18 08:26 ldap_child.log
-rw------- 1 root root 18K Jul 26 07:03 ldap_child.log-20160720.gz
-rw------- 1 root root 1.5M Aug 18 08:25 ldap_child.log-20160727
-rw------- 1 root root 19M Aug 18 08:28 sssd_ad.wsu.edu.log
-rw------- 1 root root 497K Aug 8 03:37 sssd_ad.wsu.edu.log-20160808.gz
-rw------- 1 root root 53M Aug 14 03:47 sssd_ad.wsu.edu.log-20160814
-rw------- 1 root root 0 May 10 10:43 sssd.log
-rw------- 1 root root 593K Aug 18 08:25 sssd_nss.log
-rw------- 1 root root 3.8K Aug 12 03:14 sssd_nss.log-20160812.gz
-rw------- 1 root root 722K Aug 14 03:49 sssd_nss.log-20160814
-rw------- 1 root root 0 May 10 10:43 sssd_pam.log
I restarted the daemon and cleared cache with `sss_cache -E`, still gets
the same error. Oddly, this is not effecting all of my systems. On
some, the group works:
$ getent group 7021
its_p_sto_qa_hpc_kamiak-kelley:*:7021:person1,person2,whatever
The working and failing systems are running the same version of sssd:
# salt -L cn31,cn33,cn29,cn5,cn34,cn17 cmd.run 'rpm -q sssd' # broken nodes
cn33:
sssd-1.13.0-40.el7_2.2.x86_64
cn29:
sssd-1.13.0-40.el7_2.2.x86_64
cn31:
sssd-1.13.0-40.el7_2.2.x86_64
cn34:
sssd-1.13.0-40.el7_2.2.x86_64
cn17:
sssd-1.13.0-40.el7_2.2.x86_64
cn5:
sssd-1.13.0-40.el7_2.2.x86_64
# salt -L cn28,cn16,cn44,cn1,cn42,cn9 cmd.run 'rpm -q sssd' # working nodes
cn16:
sssd-1.13.0-40.el7_2.2.x86_64
cn28:
sssd-1.13.0-40.el7_2.2.x86_64
cn42:
sssd-1.13.0-40.el7_2.2.x86_64
cn1:
sssd-1.13.0-40.el7_2.2.x86_64
cn44:
sssd-1.13.0-40.el7_2.2.x86_64
cn9:
sssd-1.13.0-40.el7_2.2.x86_64
So what now? How can I determine what sssd is unhappy about?
--
Jeff White
HPC Systems Engineer
Information Technology Services - WSU
7 years, 7 months
Mounting NFS over cross domains
by Joakim Tjernlund
Feels like I am very close to having integrated our two domains but one thing remains ...
I have a NFSv4(sec=krb5i,sec=krb5) server in realm TRANSMODE.SE and a NFS client in INFINERA.COM realm
and automounts the NFS share in the client.
This all works, I get access in the client and kan access files but all
files are listed with user=nobody, group=nobody:
ls -l
total 48
drwxrws--- 2 nobody nobody 104 Aug 17 15:34 ./
drwxrws--- 15 nobody nobody 4096 Aug 17 16:16 ../
-rwxrwx--- 1 nobody nobody 7 Aug 17 15:34 dasdsad.txt*
-rwxrwx--- 1 nobody nobody 6180 Aug 17 15:34 New Microsoft Excel Worksheet.xlsx*
-rwxrwx--- 1 nobody nobody 11292 Aug 17 15:34 New Microsoft Word Document.docx*
Any idea how I can get the correct user/group IDs listed ?
Jocke
7 years, 7 months
Re: Group Enumeration Issue
by Douglas Duckworth
Michael
I have the same number of users and groups present in output of "getent
passwd" and "getent group" vs host which is configured with pam_ldap and
ldap_nss but not sssd.
If I specify in /etc/nsswitch.conf, shown below, thus removing order "files
ldap sss," then restarting sssd and nslcd things still work.
passwd: files sss
shadow: files sss
group: files sss
So is there *really* an issue?
The OS:
Red Hat Enterprise Linux AS release 4 (Nahant Update 3)
The LDAP:
OpenLDAP: slapd 2.2.13 (Aug 18 2005 22:23:00)
Thanks again for so much assistance.
Doug
Thanks,
Douglas Duckworth, MSc, LFCS
HPC System Administrator
Physiology and Biophysics
Weill Cornell Medicine
E: doug(a)med.cornell.edu
O: 212-746-5454
F: 212-746-8690
On Tue, Aug 16, 2016 at 6:37 PM, Michael Ströder <michael(a)stroeder.com>
wrote:
> Douglas Duckworth wrote:
> > Thanks so much for the assistance.
> >
> > Added:
> >
> > ldap_disable_paging = true
> >
> > Does this mean the problem's resolved?
> >
> > I login successfully then error repeats....
>
> So the issue is likely not solved. ;-)
>
> Which LDAP server is this?
>
> Note that you might run into a size or time limit while retrieving all
> entries.
> I'd check with ldapsearch command-line tool binding as the very same
> identity
> whether you can retrieve all needed entries via LDAP.
>
> Ciao, Michael.
>
>
7 years, 7 months
DNS resolver broken in sssd?
by Ondrej Valousek
Hi list,
I am regularly getting messages like:
(Mon Aug 8 21:20:19 2016) [sssd[be[default]]] [be_resolve_server_process] (0x0080): Couldn't resolve server (myserver.com), resolver returned (5)
Or
(Wed Aug 10 15:47:46 2016) [sssd[be[default]]] [nsupdate_get_addrs_done] (0x0040): Could not resolve address for this machine, error [5]: Input/output error, resolver returned: [11]: Could not contact DNS servers
I am also running TCPdump in the background - no DNS query has been performed at the time of the error and my dns servers are working fine.
What could be the reason?
Thanks,
Ondrej
-----
The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications(a)s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18.
7 years, 7 months
Re: Group Enumeration Issue
by Douglas Duckworth
Thanks so much for the assistance.
Added:
ldap_disable_paging = true
Does this mean the problem's resolved?
I login successfully then error repeats....
(Tue Aug 16 09:55:41 2016) [sssd[be[LDAP]]] [sdap_get_generic_op_finished]
(0x0040): Unexpected result from ldap: Protocol error(2), paged results
cookie is invalid
(Tue Aug 16 09:55:41 2016) [sssd[be[LDAP]]] [generic_ext_search_handler]
(0x0040): sdap_get_generic_ext_recv failed [5]: Input/output error
(Tue Aug 16 09:55:41 2016) [sssd[be[LDAP]]] [sdap_get_users_done] (0x0040):
Failed to retrieve users
(Tue Aug 16 09:55:41 2016) [sssd[be[LDAP]]] [sdap_dom_enum_ex_users_done]
(0x0040): User enumeration failed: 5: Input/output error
(Tue Aug 16 09:55:41 2016) [sssd[be[LDAP]]] [be_ptask_done] (0x0040): Task
[enumeration]: failed with [5]: Input/output error
(Tue Aug 16 09:58:43 2016) [sssd[be[LDAP]]] [be_res_get_opts] (0x0100):
Lookup order: ipv4_first
(Tue Aug 16 09:58:43 2016) [sssd[be[LDAP]]] [recreate_ares_channel]
(0x0100): Initializing new c-ares channel
(Tue Aug 16 09:58:43 2016) [sssd[be[LDAP]]] [monitor_common_send_id]
(0x0100): Sending ID: (%BE_LDAP,1)
(Tue Aug 16 09:58:43 2016) [sssd[be[LDAP]]] [sss_names_init_from_args]
(0x0100): Using re [(?P<name>[^@]+)@?(?P<domain>[^@]*$)].
(Tue Aug 16 09:58:43 2016) [sssd[be[LDAP]]] [sss_fqnames_init] (0x0100):
Using fq format [%1$s@%2$s].
Later:
(Tue Aug 16 09:58:43 2016) [sssd[be[LDAP]]] [sdap_cli_auth_step] (0x0100):
expire timeout is 900
(Tue Aug 16 09:58:43 2016) [sssd[be[LDAP]]] [set_server_common_status]
(0x0100): Marking server 'old dinosaur' as 'working'
(Tue Aug 16 09:58:43 2016) [sssd[be[LDAP]]] [be_client_init] (0x0100):
Set-up Backend ID timeout [0x177a8f0]
(Tue Aug 16 09:58:43 2016) [sssd[be[LDAP]]] [be_client_init] (0x0100):
Set-up Backend ID timeout [0x177d690]
(Tue Aug 16 09:58:43 2016) [sssd[be[LDAP]]] [client_registration] (0x0100):
Cancel DP ID timeout [0x177a8f0]
(Tue Aug 16 09:58:43 2016) [sssd[be[LDAP]]] [client_registration] (0x0100):
Added Frontend client [NSS]
(Tue Aug 16 09:58:43 2016) [sssd[be[LDAP]]] [enum_users_done] (0x0100):
Users higher USN value: [20160816071917Z] <---- enumeration works?
(Tue Aug 16 09:58:43 2016) [sssd[be[LDAP]]] [client_registration] (0x0100):
Cancel DP ID timeout [0x177d690]
(Tue Aug 16 09:58:43 2016) [sssd[be[LDAP]]] [client_registration] (0x0100):
Added Frontend client [PAM]
(Tue Aug 16 09:58:44 2016) [sssd[be[LDAP]]] [sdap_process_group_send]
(0x0040): No Members. Done! <------ this repeats much - only showing one
line for sake of space
(Tue Aug 16 09:58:44 2016) [sssd[be[LDAP]]] [enum_groups_done] (0x0100):
Groups higher USN value: [20160727234025Z] <---- enumeration works?
I type getent passwd / group:
(Tue Aug 16 10:03:43 2016) [sssd[be[LDAP]]] [sdap_get_users_done] (0x0040):
Failed to retrieve users
(Tue Aug 16 10:08:17 2016) [sssd[be[LDAP]]] [acctinfo_callback] (0x0100):
Request processed. Returned 0,0,Success
(Tue Aug 16 10:08:39 2016) [sssd[be[LDAP]]] [acctinfo_callback] (0x0100):
Request processed. Returned 0,0,Success
(Tue Aug 16 10:08:43 2016) [sssd[be[LDAP]]] [sdap_get_users_done] (0x0040):
Failed to retrieve users
Greater logging with me typing "getent user" attached...
I am not able to see any issues. I can post more extensive logs if that
would be helpful.
Thanks
Doug
Thanks,
Douglas Duckworth, MSc, LFCS
HPC System Administrator
Physiology and Biophysics
Weill Cornell Medicine
E: doug(a)med.cornell.edu
O: 212-746-5454
F: 212-746-8690
On Tue, Aug 16, 2016 at 5:29 AM, Michael Ströder <michael(a)stroeder.com>
wrote:
> Jakub Hrozek wrote:
> > This is a different issue now. It looks like the server does not support
> > paged searches correctly or has issues with the paging support, because
> > it sends an invalid cookie (the invalid cookie message is reported by
> > openldap-libs..)
> > [..]
> > I wonder if it would be possible to increase the page size with the
> > ldap_page_size option to make the enumeration results fit into one page?
>
> Or simply use
>
> ldap_disable_paging = true
>
> Note that only AD allows circumventing search limits with this extended
> control.
> All other LDAP servers I know and especially OpenLDAP enforce the search
> size
> limits also with paged search.
>
> Ciao, Michael.
>
>
7 years, 7 months
Re: Group Enumeration Issue
by Douglas Duckworth
Thank you Jakub
I understand what we're doing isn't supported and horrible practice. We
are replacing the insecure LDAP server very soon.
I set ldap_uri = ldap://BLAH in sssd.conf and seems to be working despite
expired cert. Though there are some error messages I would like to resolve.
We are using host-based access control:
auth_provider = ldap
access_provider = ldap
ldap_access_order = host
ldap_user_authorized_host = host
As you can see sdap_access_host does grant access to accounts with the host
attribute:
(Mon Aug 15 11:21:13 2016) [sssd[be[LDAP]]] [fo_resolve_service_send]
(0x0100): Trying to resolve service 'LDAP'
(Mon Aug 15 11:21:13 2016) [sssd[be[LDAP]]] [sdap_cli_auth_step] (0x0100):
expire timeout is 900
(Mon Aug 15 11:21:13 2016) [sssd[be[LDAP]]] [fo_set_port_status] (0x0100):
Marking port 389 of server 'BLAH' as 'working'
(Mon Aug 15 11:21:13 2016) [sssd[be[LDAP]]] [set_server_common_status]
(0x0100): Marking server 'BLAH as 'working'
(Mon Aug 15 11:21:13 2016) [sssd[be[LDAP]]] [acctinfo_callback] (0x0100):
Request processed. Returned 0,0,Success
(Mon Aug 15 11:21:13 2016) [sssd[be[LDAP]]] [acctinfo_callback] (0x0100):
Request processed. Returned 0,0,Success
(Mon Aug 15 11:21:13 2016) [sssd[be[LDAP]]] [be_pam_handler] (0x0100): Got
request with the following data
(Mon Aug 15 11:21:13 2016) [sssd[be[LDAP]]] [pam_print_data] (0x0100):
command: SSS_PAM_ACCT_MGMT
(Mon Aug 15 11:21:13 2016) [sssd[be[LDAP]]] [pam_print_data] (0x0100):
domain: LDAP
(Mon Aug 15 11:21:13 2016) [sssd[be[LDAP]]] [pam_print_data] (0x0100):
user: sysadmin
(Mon Aug 15 11:21:13 2016) [sssd[be[LDAP]]] [pam_print_data] (0x0100):
service: sshd
(Mon Aug 15 11:21:13 2016) [sssd[be[LDAP]]] [pam_print_data] (0x0100): tty:
ssh
(Mon Aug 15 11:21:13 2016) [sssd[be[LDAP]]] [pam_print_data] (0x0100):
ruser:
(Mon Aug 15 11:21:13 2016) [sssd[be[LDAP]]] [pam_print_data] (0x0100):
rhost: proxy
(Mon Aug 15 11:21:13 2016) [sssd[be[LDAP]]] [pam_print_data] (0x0100):
authtok type: 0
(Mon Aug 15 11:21:13 2016) [sssd[be[LDAP]]] [pam_print_data] (0x0100):
newauthtok type: 0
(Mon Aug 15 11:21:13 2016) [sssd[be[LDAP]]] [pam_print_data] (0x0100):
priv: 1
(Mon Aug 15 11:21:13 2016) [sssd[be[LDAP]]] [pam_print_data] (0x0100):
cli_pid: 11864
(Mon Aug 15 11:21:13 2016) [sssd[be[LDAP]]] [pam_print_data] (0x0100):
logon name: not set
(Mon Aug 15 11:21:13 2016) [sssd[be[LDAP]]] [sdap_access_host] (0x0100):
Access granted for [CLIENT]
(Mon Aug 15 11:21:13 2016) [sssd[be[LDAP]]] [be_pam_handler_callback]
(0x0100): Backend returned: (0, 0, <NULL>) [Success]
(Mon Aug 15 11:21:13 2016) [sssd[be[LDAP]]] [be_pam_handler_callback]
(0x0100): Sending result [0][LDAP]
(Mon Aug 15 11:21:13 2016) [sssd[be[LDAP]]] [be_pam_handler_callback]
(0x0100): Sent result [0][LDAP]
(Mon Aug 15 11:21:13 2016) [sssd[be[LDAP]]] [be_pam_handler] (0x0100): Got
request with the following data
(Mon Aug 15 11:21:13 2016) [sssd[be[LDAP]]] [pam_print_data] (0x0100):
command: SSS_PAM_ACCT_MGMT
(Mon Aug 15 11:21:13 2016) [sssd[be[LDAP]]] [pam_print_data] (0x0100):
domain: LDAP
(Mon Aug 15 11:21:13 2016) [sssd[be[LDAP]]] [pam_print_data] (0x0100):
user: sysadmin
(Mon Aug 15 11:21:13 2016) [sssd[be[LDAP]]] [pam_print_data] (0x0100):
service: sshd
(Mon Aug 15 11:21:13 2016) [sssd[be[LDAP]]] [pam_print_data] (0x0100): tty:
ssh
(Mon Aug 15 11:21:13 2016) [sssd[be[LDAP]]] [pam_print_data] (0x0100):
ruser:
(Mon Aug 15 11:21:13 2016) [sssd[be[LDAP]]] [pam_print_data] (0x0100):
rhost: proxy
(Mon Aug 15 11:21:13 2016) [sssd[be[LDAP]]] [pam_print_data] (0x0100):
authtok type: 0
(Mon Aug 15 11:21:13 2016) [sssd[be[LDAP]]] [pam_print_data] (0x0100):
newauthtok type: 0
(Mon Aug 15 11:21:13 2016) [sssd[be[LDAP]]] [pam_print_data] (0x0100):
priv: 1
(Mon Aug 15 11:21:13 2016) [sssd[be[LDAP]]] [pam_print_data] (0x0100):
cli_pid: 11864
(Mon Aug 15 11:21:13 2016) [sssd[be[LDAP]]] [pam_print_data] (0x0100):
logon name: not set
(Mon Aug 15 11:21:13 2016) [sssd[be[LDAP]]] [sdap_access_host] (0x0100):
Access granted for [CLIENT]
Though right before the above successful login we see:
(Mon Aug 15 11:16:54 2016) [sssd[be[LDAP]]] [fo_set_port_status] (0x0100):
Marking port 389 of server 'BLAH as 'working'
(Mon Aug 15 11:16:54 2016) [sssd[be[LDAP]]] [set_server_common_status]
(0x0100): Marking server 'BLAH' as 'working'
(Mon Aug 15 11:16:54 2016) [sssd[be[LDAP]]] [sdap_get_generic_op_finished]
(0x0040): Unexpected result from ldap: Protocol error(2), paged results
cookie is invalid
(Mon Aug 15 11:16:54 2016) [sssd[be[LDAP]]] [generic_ext_search_handler]
(0x0040): sdap_get_generic_ext_recv failed [5]: Input/output error
(Mon Aug 15 11:16:54 2016) [sssd[be[LDAP]]] [sdap_get_users_done] (0x0040):
Failed to retrieve users
(Mon Aug 15 11:16:54 2016) [sssd[be[LDAP]]] [sdap_dom_enum_ex_users_done]
(0x0040): User enumeration failed: 5: Input/output error
(Mon Aug 15 11:16:54 2016) [sssd[be[LDAP]]] [be_ptask_done] (0x0040): Task
[enumeration]: failed with [5]: Input/output error
Does this mean that enumeration occurs not with SSSD but NSS?
Thanks,
Douglas Duckworth, MSc, LFCS
HPC System Administrator
Physiology and Biophysics
Weill Cornell Medicine
E: doug(a)med.cornell.edu
O: 212-746-5454
F: 212-746-8690
On Mon, Aug 15, 2016 at 3:45 AM, Jakub Hrozek <jhrozek(a)redhat.com> wrote:
> On Fri, Aug 12, 2016 at 12:05:46PM -0400, Douglas Duckworth wrote:
> > Clarification
> >
> > This works:
> >
> > ldapsearch -x -ZZ -H ldap://blah dc=blah-x uid=me -d3
> >
> > Again says expired certificate.
> >
> > I set ldap_uri = ldaps://blah, ldap://blah and ldap_tls_reqcert = never
> in
> > sssd.conf but still failure.
>
> To be honest I'm not sure if setting the tls_reqcert value to never only
> hides the trust issues or also expiration issues.
>
> btw the ldapsearch is for ldap:// with TLS, but SSSD is asked for
> ldaps://, does sssd work with ldap:// only? (if you need confidentiality
> for identity lookups you can set ldap_id_use_start_tls. For
> authentication, TLS will be tried automatically, SSSD doesn't support
> authentication over an unencrypted channel)
> _______________________________________________
> sssd-users mailing list
> sssd-users(a)lists.fedorahosted.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.
> fedorahosted.org_admin_lists_sssd-2Dusers-40lists.
> fedorahosted.org&d=DQIGaQ&c=lb62iw4YL4RFalcE2hQUQealT9-
> RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-CbhH6xUjnRkaqPFUS2wTJ2cw&m=
> ZqsTB2JT98oTSoYAWIbe7YnWKuNrXDEVIK7i1Ljyqlg&s=
> o0iBmvS8uYOP0J6AMR_SEAGXSzzv_YQaLY4v02fCfoU&e=
>
7 years, 7 months
SSSD-PAM failure
by Thomas Beaudry
Happy <onday everyone!
I have a problem getting sssd/pam to work. I can do a getent passwd username and su finds the user, but the password authentication fails.
Here is my sssd_pam.log error log:
(Thu Aug 4 12:31:07 2016) [sssd[pam]] [pam_process_init] (0x0010): sss_process_init() failed
(Thu Aug 4 12:31:07 2016) [sssd[pam]] [sss_dp_init] (0x0010): Failed to connect to monitor services.
(Thu Aug 4 12:31:07 2016) [sssd[pam]] [sss_process_init] (0x0010): fatal error setting up backend connector
Would you know how to fix this problem? I can send you more info if you want to help. I have been googling the problem for awhile to no avail.
Thanks,
Thomas
7 years, 7 months
GSSAPI token errors
by Robert Moulton
On a CentOS 6 system we recently implemented sssd auth against an AD
domain (Samba 4 AD, specifically). The system messages log often shows
flurries of these GSSAPI errors:
sssd[be[notarealdomain.com]]: GSSAPI Error: Invalid token was supplied
(Token header is malformed or corrupt)
Any idea what might be wrong? Troubleshooting tips? (We don't have much
experience with sssd, admittedly.)
When the flurries happen, system load increases markedly, and we suspect
that a recent system crash was related.
Our sssd.conf:
----------
[sssd]
services = nss, pam
config_file_version = 2
domains = notarealdomain.com
[nss]
[pam]
[domain/notarealdomain.com]
id_provider = ad
access_provider = ad
ldap_id_mapping=false
krb5_keytab=/etc/krb5.sssd.keytab
----------
thanks in advance,
-r
7 years, 7 months
Re: Group Enumeration Issue
by Douglas Duckworth
Jakub
I had base set to Accounts OU in nslcd so I can now enumerate groups by
setting base correctly :) However I still do see this issue in sssd_LDAP
log:
(Fri Aug 12 11:28:26 2016) [sssd[be[LDAP]]] [sdap_uri_callback] (0x0400):
Constructed uri 'blah'
(Fri Aug 12 11:28:26 2016) [sssd[be[LDAP]]] [sss_ldap_init_send] (0x4000):
Using file descriptor [21] for LDAP connection.
(Fri Aug 12 11:28:26 2016) [sssd[be[LDAP]]] [sss_ldap_init_send] (0x0400):
Setting 30 seconds timeout for connecting
(Fri Aug 12 11:28:26 2016) [sssd[be[LDAP]]]
[sss_ldap_init_sys_connect_done] (0x0020): ldap_install_tls failed: Connect
error
(Fri Aug 12 11:28:26 2016) [sssd[be[LDAP]]]
[sss_ldap_init_state_destructor] (0x0400): calling ldap_unbind_ext for
ldap:[0x20333d0] sd:[21]
(Fri Aug 12 11:28:26 2016) [sssd[be[LDAP]]] [sdap_sys_connect_done]
(0x0020): sdap_async_connect_call request failed: [5]: Input/output error.
(Fri Aug 12 11:28:26 2016) [sssd[be[LDAP]]] [sdap_handle_release] (0x2000):
Trace: sh[0x202c170], connected[0], ops[(nil)], ldap[(nil)],
destructor_lock[0], release_memory[0]
(Fri Aug 12 11:28:26 2016) [sssd[be[LDAP]]] [_be_fo_set_port_status]
(0x8000): Setting status: PORT_NOT_WORKING. Called from:
src/providers/ldap/sdap_async_connection.c: sdap_cli_connect_done: 1564
(Fri Aug 12 11:28:26 2016) [sssd[be[LDAP]]] [fo_set_port_status] (0x0100):
Marking port 636 of server 'blah' as 'not working'
(Fri Aug 12 11:28:26 2016) [sssd[be[LDAP]]] [fo_set_port_status] (0x0400):
Marking port 636 of duplicate server 'blah as 'not working'
(Fri Aug 12 11:28:26 2016) [sssd[be[LDAP]]] [fo_resolve_service_send]
(0x0100): Trying to resolve service 'LDAP'
(Fri Aug 12 11:28:26 2016) [sssd[be[LDAP]]] [get_server_status] (0x1000):
Status of server 'blah is 'name resolved'
(Fri Aug 12 11:28:26 2016) [sssd[be[LDAP]]] [get_port_status] (0x1000):
Port status of port 636 for server 'blah' is 'not working'
(Fri Aug 12 11:28:26 2016) [sssd[be[LDAP]]] [fo_resolve_service_send]
(0x0020): No available servers for service 'LDAP'
(Fri Aug 12 11:28:26 2016) [sssd[be[LDAP]]] [be_resolve_server_done]
(0x1000): Server resolution failed: 5
(Fri Aug 12 11:28:26 2016) [sssd[be[LDAP]]] [check_online_callback]
(0x0100): Backend returned: (1, 0, <NULL>) [Provider is Offline]
LDAPTLS_REQCERT=never ldapsearch -Z -x uid=blah works...
ldapsearch - Z debug:
ldap_create
ldap_extended_operation_s
ldap_extended_operation
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP blah:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying blah:636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
attempting to connect:
connect success
tls_write: want=137, written=137
ldapsearch - ZZ debug shows the certificate has expired thus is not trusted.
I have "ldap_tls_reqcert = never" set in sssd.conf as a temporary measure,
while /etc/openldap/ldap.conf has "tls_reqcert allow." Shouldn't that
allow TLS to work without verifying PKI chain?
This LDAP server is over 9000 years old. We're in the process of replacing
it, as well as switching from pam_ldap to sssd, so for now I would like to
get this working even if we're undermining the purpose of PKI.
Thanks for your help!
Thanks,
Douglas Duckworth, MSc, LFCS
HPC System Administrator
Physiology and Biophysics
Weill Cornell Medicine
E: doug(a)med.cornell.edu
O: 212-746-5454
F: 212-746-8690
On Fri, Aug 12, 2016 at 4:08 AM, Jakub Hrozek <jhrozek(a)redhat.com> wrote:
> On Thu, Aug 11, 2016 at 05:17:14PM -0400, Douglas Duckworth wrote:
> > Hello
> >
> > I am able to enumerate users but not groups using "getent group."
> >
> > I believe our old LDAP server uses standard rcf2307 schema:
> >
> > # blah, Group, blah.blah.blah.edu
> > dn: cn=blah,ou=Group,dc=blah,dc=blah,dc=blah,dc=edu
> > objectClass: posixGroup
> > objectClass: top
> > cn: blahgroup
> > gidNumber: 1045
> > memberUid: blah
> >
> > I can login over ssh, use getent password, while id returns correct
> > information:
> >
> > [root@nfs-server ~]# id LUZER
> > uid=8877(LUZER) gid=1009 groups=1009
> >
> > My SSSD configuration and debug logs are attached.
> >
> > I can resolve the LDAP server and perform searches against it though the
> > logs to show repeated DNS issues. Though if DNS was a problem, and thus
> > provider offline, then how could I login and enumerate users?
>
> These messages:
> (Thu Aug 11 17:06:40 2016) [sssd[be[LDAP]]] [sss_ldap_init_sys_connect_done]
> (0x0020): ldap_install_tls failed: Connect error
> (Thu Aug 11 17:06:40 2016) [sssd[be[LDAP]]] [sss_ldap_init_state_destructor]
> (0x0400): calling ldap_unbind_ext for ldap:[0x183db80] sd:[18]
> (Thu Aug 11 17:06:40 2016) [sssd[be[LDAP]]] [sdap_sys_connect_done]
> (0x0020): sdap_async_connect_call request failed: [5]: Input/output error.
> (Thu Aug 11 17:06:40 2016) [sssd[be[LDAP]]] [sdap_handle_release]
> (0x2000): Trace: sh[0x1850770], connected[0], ops[(nil)], ldap[(nil)],
> destructor_lock[0], release_memory[0]
> (Thu Aug 11 17:06:40 2016) [sssd[be[LDAP]]] [_be_fo_set_port_status]
> (0x8000): Setting status: PORT_NOT_WORKING. Called from:
> src/providers/ldap/sdap_async_connection.c: sdap_cli_connect_done: 1564
> (Thu Aug 11 17:06:40 2016) [sssd[be[LDAP]]] [fo_set_port_status] (0x0100):
> Marking port 636 of server 'blah.blah.blah.edu' as 'not working'
> (Thu Aug 11 17:06:40 2016) [sssd[be[LDAP]]] [fo_set_port_status] (0x0400):
> Marking port 636 of duplicate server 'blah.blah.blah.edu' as 'not working'
> (Thu Aug 11 17:06:40 2016) [sssd[be[LDAP]]] [fo_resolve_service_send]
> (0x0100): Trying to resolve service 'LDAP'
> (Thu Aug 11 17:06:40 2016) [sssd[be[LDAP]]] [get_server_status] (0x1000):
> Status of server 'blah.blah.blah.edu' is 'name resolved'
> (Thu Aug 11 17:06:40 2016) [sssd[be[LDAP]]] [get_port_status] (0x1000):
> Port status of port 636 for server 'blah.blah.blah.edu' is 'not working'
> (Thu Aug 11 17:06:40 2016) [sssd[be[LDAP]]] [fo_resolve_service_send]
> (0x0020): No available servers for service 'LDAP'
> (Thu Aug 11 17:06:40 2016) [sssd[be[LDAP]]] [be_resolve_server_done]
> (0x1000): Server resolution failed: 5
> (Thu Aug 11 17:06:40 2016) [sssd[be[LDAP]]] [sdap_id_op_connect_done]
> (0x0020): Failed to connect, going offline (5 [Input/output error])
> (Thu Aug 11 17:06:40 2016) [sssd[be[LDAP]]] [be_mark_offline] (0x2000):
> Going offline!
> (Thu Aug 11 17:06:40 2016) [sssd[be[LDAP]]] [be_mark_offline] (0x2000):
> Initialize check_if_online_ptask.
> (Thu Aug 11 17:06:40 2016) [sssd[be[LDAP]]] [be_ptask_create] (0x0400):
> Periodic task [Check if online (periodic)] was created
> (Thu Aug 11 17:06:40 2016) [sssd[be[LDAP]]] [be_ptask_schedule] (0x0400):
> Task [Check if online (periodic)]: scheduling task 81 seconds from now
> [1470949681]
> (Thu Aug 11 17:06:40 2016) [sssd[be[LDAP]]] [be_run_offline_cb] (0x0080):
> Going offline. Running callbacks.
> (Thu Aug 11 17:06:40 2016) [sssd[be[LDAP]]] [sdap_id_op_connect_done]
> (0x4000): notify offline to op #1
> (Thu Aug 11 17:06:40 2016) [sssd[be[LDAP]]] [sdap_dom_enum_ex_connected]
> (0x0400): Backend is marked offline, retry later!
>
> make it look like the certificate is not correct, sssd tries to connect to
> the server and fails.
>
> Does searching the server with ldapsearch using -ZZ succeed?
> _______________________________________________
> sssd-users mailing list
> sssd-users(a)lists.fedorahosted.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.
> fedorahosted.org_admin_lists_sssd-2Dusers-40lists.
> fedorahosted.org&d=DQIGaQ&c=lb62iw4YL4RFalcE2hQUQealT9-
> RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-CbhH6xUjnRkaqPFUS2wTJ2cw&m=
> JsOPoBFWPBpJyy-yyj1h3uae8Lv75j8uDzdmH0lNtmI&s=ZGFp6o41jb-6yZ_8HbXk-
> oB3WympSLRZQDUcu0GA-CI&e=
>
7 years, 7 months
Group Enumeration Issue
by Douglas Duckworth
Hello
I am able to enumerate users but not groups using "getent group."
I believe our old LDAP server uses standard rcf2307 schema:
# blah, Group, blah.blah.blah.edu
dn: cn=blah,ou=Group,dc=blah,dc=blah,dc=blah,dc=edu
objectClass: posixGroup
objectClass: top
cn: blahgroup
gidNumber: 1045
memberUid: blah
I can login over ssh, use getent password, while id returns correct
information:
[root@nfs-server ~]# id LUZER
uid=8877(LUZER) gid=1009 groups=1009
My SSSD configuration and debug logs are attached.
I can resolve the LDAP server and perform searches against it though the
logs to show repeated DNS issues. Though if DNS was a problem, and thus
provider offline, then how could I login and enumerate users?
Any help is greatly appreciated and may engender free booze if you're in
New York.
Thanks!
Doug
Thanks,
Douglas Duckworth, MSc, LFCS
HPC System Administrator
Physiology and Biophysics
Weill Cornell Medicine
E: doug(a)med.cornell.edu
O: 212-746-5454
F: 212-746-8690
7 years, 7 months