[PATCH] LDAP: Fix memory leaks in synchronous_tls_setup
by Stephen Gallagher
We were never freeing "result" if it was allocated by
ldap_result(). We were also not freeing "errmsg" if it was
allocated but ldap_parse_result() returned an error.
Also disambiguate error messages from ldap_parse_result() and
error messages from sss_ldap_get_diagnostic_msg() since they use
differing memory-management functions.
12 years
[PATCH] Add idmap library
by Sumit Bose
Hi,
this patch adds a library to map a Windows SID to a Unix uid or gid. My
current plan is to used it for AD trusts on the client and the server
side, this is why the interface allows different kind of memory
allocators.
bye,
Sumit
12 years
Problem in sssd and libsss_autofs
by Marco Pizzoli
Hi guys,
I would like to report this packaging(?) problem.
As you can see in the following output, there's not a dependency between
the rpm libsss_autofs and sssd.
I hope to be of help.
Marco
[root@myhostname ~]# rpm -qa|grep sss
libsss_sudo-1.8.0-6.fc16.x86_64
sssd-1.8.0-6.fc16.x86_64
libsss_autofs-1.8.0-6.fc16.x86_64
sssd-client-1.8.0-6.fc16.x86_64
[root@ myhostname ~]# yum update sssd
Loaded plugins: langpacks, presto, refresh-packagekit
updates/metalink
| 24 kB 00:00
updates
| 4.5 kB 00:00
updates/primary_db
| 5.6 MB 00:11
updates/group_gz
| 431 kB 00:00
updates-testing/metalink
| 20 kB 00:00
updates-testing
| 4.5 kB 00:00
updates-testing/primary_db
| 1.1 MB 00:01
updates-testing/group_gz
| 431 kB 00:02
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package sssd.x86_64 0:1.8.0-6.fc16 will be updated
---> Package sssd.x86_64 0:1.8.1-8.fc16 will be an update
--> Processing Dependency: sssd-client(x86-64) = 1.8.1-8.fc16 for package:
sssd-1.8.1-8.fc16.x86_64
--> Processing Dependency: libipa_hbac(x86-64) = 1.8.1-8.fc16 for package:
sssd-1.8.1-8.fc16.x86_64
--> Running transaction check
---> Package libipa_hbac.x86_64 0:1.8.0-6.fc16 will be updated
--> Processing Dependency: libipa_hbac = 1.8.0-6.fc16 for package:
libipa_hbac-python-1.8.0-6.fc16.x86_64
---> Package libipa_hbac.x86_64 0:1.8.1-8.fc16 will be an update
---> Package sssd-client.x86_64 0:1.8.0-6.fc16 will be updated
---> Package sssd-client.x86_64 0:1.8.1-8.fc16 will be an update
--> Running transaction check
---> Package libipa_hbac-python.x86_64 0:1.8.0-6.fc16 will be updated
---> Package libipa_hbac-python.x86_64 0:1.8.1-8.fc16 will be an update
--> Finished Dependency Resolution
Dependencies Resolved
==============================================================================================================================================
Package Arch Version
Repository Size
==============================================================================================================================================
Updating:
sssd x86_64
1.8.1-8.fc16 updates-testing 1.8 M
Updating for dependencies:
libipa_hbac x86_64
1.8.1-8.fc16 updates-testing 45 k
libipa_hbac-python x86_64
1.8.1-8.fc16 updates-testing 40 k
sssd-client x86_64
1.8.1-8.fc16 updates-testing 75 k
Transaction Summary
==============================================================================================================================================
Upgrade 4 Packages
Total download size: 1.9 M
Is this ok [y/N]: y
Downloading Packages:
Setting up and reading Presto delta metadata
updates-testing/prestodelta
| 176 kB 00:01
Processing delta metadata
Package(s) data still to download: 1.9 M
(1/4): libipa_hbac-1.8.1-8.fc16.x86_64.rpm
| 45 kB 00:00
(2/4): libipa_hbac-python-1.8.1-8.fc16.x86_64.rpm
| 40 kB 00:00
(3/4): sssd-1.8.1-8.fc16.x86_64.rpm
| 1.8 MB 00:06
(4/4): sssd-client-1.8.1-8.fc16.x86_64.rpm
| 75 kB 00:00
----------------------------------------------------------------------------------------------------------------------------------------------
Total
180 kB/s | 1.9 MB 00:11
Running Transaction Check
Running Transaction Test
*Transaction Check Error:*
* file /usr/lib64/sssd/modules/libsss_autofs.so from install of
sssd-1.8.1-8.fc16.x86_64 conflicts with file from package
libsss_autofs-1.8.0-6.fc16.x86_64*
Error Summary
-------------
[root@ myhostname ~]# yum update sssd libsss_autofs
Loaded plugins: langpacks, presto, refresh-packagekit
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package libsss_autofs.x86_64 0:1.8.0-6.fc16 will be updated
---> Package libsss_autofs.x86_64 0:1.8.1-8.fc16 will be an update
---> Package sssd.x86_64 0:1.8.0-6.fc16 will be updated
---> Package sssd.x86_64 0:1.8.1-8.fc16 will be an update
--> Processing Dependency: sssd-client(x86-64) = 1.8.1-8.fc16 for package:
sssd-1.8.1-8.fc16.x86_64
--> Processing Dependency: libipa_hbac(x86-64) = 1.8.1-8.fc16 for package:
sssd-1.8.1-8.fc16.x86_64
--> Running transaction check
---> Package libipa_hbac.x86_64 0:1.8.0-6.fc16 will be updated
--> Processing Dependency: libipa_hbac = 1.8.0-6.fc16 for package:
libipa_hbac-python-1.8.0-6.fc16.x86_64
---> Package libipa_hbac.x86_64 0:1.8.1-8.fc16 will be an update
---> Package sssd-client.x86_64 0:1.8.0-6.fc16 will be updated
---> Package sssd-client.x86_64 0:1.8.1-8.fc16 will be an update
--> Running transaction check
---> Package libipa_hbac-python.x86_64 0:1.8.0-6.fc16 will be updated
---> Package libipa_hbac-python.x86_64 0:1.8.1-8.fc16 will be an update
--> Finished Dependency Resolution
Dependencies Resolved
==============================================================================================================================================
Package Arch Version
Repository Size
==============================================================================================================================================
Updating:
libsss_autofs x86_64
1.8.1-8.fc16 updates-testing 48 k
sssd x86_64
1.8.1-8.fc16 updates-testing 1.8 M
Updating for dependencies:
libipa_hbac x86_64
1.8.1-8.fc16 updates-testing 45 k
libipa_hbac-python x86_64
1.8.1-8.fc16 updates-testing 40 k
sssd-client x86_64
1.8.1-8.fc16 updates-testing 75 k
Transaction Summary
==============================================================================================================================================
Upgrade 5 Packages
Total size: 2.0 M
Total download size: 48 k
Is this ok [y/N]: y
Downloading Packages:
Setting up and reading Presto delta metadata
libsss_autofs-1.8.1-8.fc16.x86_64.rpm
| 48 kB 00:00
Running Transaction Check
Running Transaction Test
Transaction Test Succeeded
Running Transaction
Updating : libipa_hbac-1.8.1-8.fc16.x86_64
1/10
Updating : sssd-client-1.8.1-8.fc16.x86_64
2/10
Updating : sssd-1.8.1-8.fc16.x86_64
3/10
Updating : libipa_hbac-python-1.8.1-8.fc16.x86_64
4/10
Updating : libsss_autofs-1.8.1-8.fc16.x86_64
5/10
Cleanup : sssd-1.8.0-6.fc16.x86_64
6/10
Cleanup : libipa_hbac-python-1.8.0-6.fc16.x86_64
7/10
Cleanup : libipa_hbac-1.8.0-6.fc16.x86_64
8/10
Cleanup : sssd-client-1.8.0-6.fc16.x86_64
9/10
Cleanup : libsss_autofs-1.8.0-6.fc16.x86_64
10/10
Updated:
libsss_autofs.x86_64 0:1.8.1-8.fc16
sssd.x86_64 0:1.8.1-8.fc16
Dependency Updated:
libipa_hbac.x86_64 0:1.8.1-8.fc16 libipa_hbac-python.x86_64
0:1.8.1-8.fc16 sssd-client.x86_64 0:1.8.1-8.fc16
Complete!
12 years
Active Directory integration issues
by Rolf Loudon
Hello
I've installed sssd 1.5 on an ubuntu 11.10 server. I've followed the howto at
https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate...
I wish to use SASL as the authentication to the AD KDC. I add the computer account to the domain and test it as described with
kinit -k -t /etc/krb5.keytab host/myhostname.domain.name(a)REALM.NAME
then
ldapsearch -h ad.kdc -b "dc=domainpart1,dc=domainpart2,dc=domainpart3" -Y GSSAPI cn=someuser
and that all works fine.
When I use this setup within sssd there are a two main issues.
Firstly the logs tell me that the principal is not found in the KDC database. But when I inspect it using ADSI Edit I see the SPN and UPN values that I expect to see and that match the principal it says it cannot find. Likewise these principals can be seen from klist -kte /etc/krb5/keytab (though it doesn't complain about not finding anything in the key tab)
I can get round that issue temporarily by specifying the principal name using ldap_sasl_authid. I'd still like to know what is wrong in that instance.
Secondly the ldap_search_base strangely affects the authentication and the user lookup. I don't know if the searching is subtree or not. I can't see a parameter to make this explicit.
If I set ldap_search_base (or ldap_user_search_base) to dc=domainpart1,dc=domainpart2,dc=domainpart3 then I get errors about ldap_sasl_interactive_bind_s failing.
however if I set the ldap_search_base to cn=users,dc=domainpart1,dc=domainpart2,dc=domainpart3 then those errors go away and the lookup is done.
The problem is that the users do not live in cn=users,dc=domainpart1,dc=domainpart2,dc=domainpart3 they are in an OU elsewhere. They can be found via a subtree search (as per the ldapsearch example above) if the search base is set to higher up the tree at just the domain components specification.
But if I set the search base that way, then the sasl bind fails.
Using both ldap_search_base and ldap_user_search_base makes no difference.
Is there are way to separately define where the ldap_sasl_bind looks (unless I misunderstand it needs to look for the computer account, which is in cn=computers,dc=... which is also not within cn=users,dc=... so its still confusing me) so that the search base can be set so the user lookup will work.
I can successfully lookup the user if I use a simple bind with ldap_default_bind_dn and ldap_default_authtok rather than sasl. And can show that the ldap_search_base affects this lookup in the above way.
Really appreciate any pointers to these two problems.
many thanks
r.
12 years, 1 month
[PATCH] Save alias of the service primary name, too
by Jakub Hrozek
After the recent changes to sysdb_attrs_get_aliases() we stopped saving
the lowercased alias of the primary name.
Services are a different beast than the rest of the entries, because
with everything else the nss responder only uses the alias to match the
entry. With services, we also need to print the aliases.
The attached patch changes the behaviour so that all aliases are saved
lowercased in an insensitive domain, including the primary name, but
when returning the service, the alias that matches the primary name is
filtered out. Because all aliases are lowercased now, I also removed the
sss_get_cased_name() call, it is no longer needed.
12 years, 1 month
[PATCH] LDAP: Add better error logging when ldap_result() fails
by Stephen Gallagher
This should help us diagnose issues with ldap_result() returning -1.
The only catch is that it relies on the openldap libraries setting the
error code properly, which they do not always do.*
* As part of my tests, I reverted the openldap libraries to the 2.4.29
release that was broken with SSSD, causing ldap_result to return -1 all
the time. The LDAP_OPT_RESULT_CODE in that case was LDAP_SUCCESS.
12 years, 1 month
