This patch should not be pushed to master, but I would like to get it
It should be used to provide a custom build for users experiencing cases
where ldap_search_ext would block (c.f.
would set LDAP_DEBUG_ANY
The attached patch applies cleanly on the RHEL6.1 branch. I also have a
version that applies on master/1.5 if needed.
Please see the attached patches. I tried to split the patches logically
into manageable sets.
Unfortunately I made a minor mistake and I am afraid I will do something
wrong to fix it.
I merged two wrong patches. Fortunately it was three liner with 1 liner
so it is not a big of the deal but I am really scared that I will do
something wrong and loose the work I have done.
So I hope it is Ok to send it as is.
0001--INI-Making-Coverity-happy.patch <- this is the patch I submitted
earlier that I merged by mistake. I was supposed to merge it with patch
25 but picked the wrong one instead.
Patch 25 addresses the real issue found by Coverity as mentioned in
Stephen's review mail but it did not apply cleanly since it relies on
some code from the patches in the middle.
0002--INI-Adding-missing-function-declararion.patch <- this is the
patch that was rejected from the second set sent earlier. Fixed
according to review comment.
0003--BUILD-Allow-trace-per-component.patch <- This patch allows tracing
The following set of patches introduces the merging of sections during
the reading of the file:
Patches related porting of the meta data from old way of doing things to
the new way of doing things:
0021--INI-Avoid-double-free.patch <- patch related to 17 (missed check)
0024--INI-Rename-error-print-function.patch <- rename error printing
function for consistency with new interface
0025--INI-Initialize-variables-in-loops.patch <- Coverity issue
addressed. Related to patch 0001.
0026--INI-Exposing-functions.patch <- Make some internal functions reusable
There is also patch 27. It is a piece of new functionality. It is a
preview. Please see the comment before reviewing it.
Do I need to split it into multiple patches or it is Ok as is? It is
pretty big but all changes are in one file and logically related.
The UNIT test is missing so I am not claiming it actually works as
Sr. Engineering Manager IPA project,
Red Hat Inc.
Looking to carve out IT costs?
https://fedorahosted.org/sssd/ticket/924 started as a segfault ticket
but we could never reproduce the crash afterwards.
As Sumit noted it might have been caused by setting the O_NONBLOCK flag
twice. However, the changes Sumit proposed in the ticket still make
sense because they provide much cleaner solution.
Attached are two patches:
[PATCH 1/2] Provide means of forcing TLS and GSSAPI enabled/disabled
for sdap connections
This will be used to force TLS on the auth connection only and allow
staying on GSSAPI-backed ID connection for the rest of the request.
[PATCH 2/2] IPA migration fixes
* use the id connection for looking up the migration flag
* force TLS on the password based authentication connection
Attached patch rewrites almost entire memberof plugin. It heavily utilizes
hash tables instead of lists and arrays and it introduces concept of reference
counting which should heavily optimize all operations when no loops are
present in the user/group tree.
I tested the patch by running sysdb test suite, all tests passed. I also
attach a document where basic concepts of the plugin are explained.
Please note that the patch is functional, although I don't consider it ready.
I just want to get pre-ACK or some comments about the patch design. I have yet
to implement the recompute task, I will work on that later.
We've been experimenting with putty v0.61 and windows SSO authentication. e.g. You log into windows with username "tim" and when then load up putty and try and connect to a RHEL6 machine, it passes along my Windows GSSAPI credentials and automatically logs me in to the RHEL6 box.
SSSD has been configured to talk to Active Directory like so:
enumerate = True
ldap_id_use_start_tls = False
cache_credentials = True
id_provider = ldap
auth_provider = krb5
chpass_provider = krb5
debug_level = 1
ldap_schema = rfc2307bis
ldap_force_upper_case_realm = True
ldap_user_object_class = user
ldap_group_object_class = group
ldap_user_home_directory = unixHomeDirectory
ldap_user_name = msSFU30Name
ldap_user_member_of = msSFU30PosixMemberOf
ldap_group_member = msSFU30PosixMember
access_provider = ldap
ldap_uri = ldap://xxxx/
ldap_search_base = xxx
ldap_user_search_base = xxx
ldap_group_search_base = xxx
ldap_sasl_mech = gssapi
ldap_sasl_authid = xxx
ldap_krb5_keytab = xxx
ldap_krb5_init_creds = true
ldap_tls_cacertdir = /etc/openldap/cacerts
krb5_realm = xxx
krb5_kpasswd = xxx
krb5_server = xxx
What we're finding is Windows for some reason stores the username in UPPERCASE and passes the uppercase value in the GSSAPI credentials. However the username attribute in AD (msSFU30Name) stores the username in lowercase, which is the standard for Unix usernames and something we are very comfortable with.
Because the username comparison is case-sensitive, the user is denied access. If we hard-code the login name in putty to be lowercase it works, so I'm pretty sure the GSSAPI auth is working.
So, my question is: Is there a way to make the username comparison to LDAP case-insensitive? Or do we need to update our AD/LDAP to uppercase all the msSFU30Name attributes? Or is there another option?
I understand usernames should be compared case-sensitive to be POSIX compliant. I've just been asked to see if I can get this to work.
BTW I've been browsing trac and it looks like you were considering a "force_lowercase_names" config option at one point. Is this still under consideration? https://fedorahosted.org/sssd/ticket/246
This e-mail is sent by Suncorp Group Limited ABN 66 145 290 124 or one of its related entities "Suncorp".
Suncorp may be contacted at Level 18, 36 Wickham Terrace, Brisbane or on 13 11 55 or at suncorp.com.au.
The content of this e-mail is the view of the sender or stated author and does not necessarily reflect the view of Suncorp. The content, including attachments, is a confidential communication between Suncorp and the intended recipient. If you are not the intended recipient, any use, interference with, disclosure or copying of this e-mail, including attachments, is unauthorised and expressly prohibited. If you have received this e-mail in error please contact the sender immediately and delete the e-mail and any attachments from your system.