Hi,
this patch addresses https://fedorahosted.org/sssd/ticket/109. It should
now be possbile to get users with 'UNIX attributes' set from AD. For me
the following config options worked:
...
provider = ldap
ldapUri = ldap://your.ldap.server
userSearchBase = cn=users,dc=example,dc=com
groupSearchBase = cn=groups,dc=example,dc=com
defaultBindDn = cn=Administrator,cn=Users,dc=example,dc=com
defaultAuthtokType = password
defaultAuthtok = YOUR_PASSWORD
userObjectClass = person
userName = msSFU30Name
userUidNumber = msSFU30UidNumber
userGidNumber = msSFU30GidNumber
userHomeDirectory = msSFU30HomeDirectory
userShell = msSFU30LoginShell
tls_reqcert = never
...
I'm currently trying to get authentication against AD working, too. I
will include a sample configuration and more man page option with a
following patch.
bye,
Sumit
Hi,
While building sssd on Karmic, the following warnings are generated
during the build [1]:
dpkg-shlibdeps: warning: dependency on libcom_err.so.2 could be
avoided if "debian/sssd/usr/lib/sssd/libsss_krb5.so.1.0.0" were not
uselessly linked against it (they use none of its symbols).
dpkg-shlibdeps: warning: dependency on libssl3.so could be avoided if
"debian/sssd/usr/sbin/sss_groupdel
debian/sssd/usr/lib/sssd/sssd/sssd_nss debian/sssd/usr/sbin/sssd
debian/sssd/usr/sbin/sss_userdel debian/sssd/usr/lib/sssd/sssd/sssd_be
debian/sssd/usr/lib/sssd/sssd/sssd_pam
debian/sssd/usr/lib/sssd/sssd/sssd_dp debian/sssd/usr/sbin/sss_useradd
debian/sssd/usr/sbin/sss_groupmod debian/sssd/usr/sbin/sss_groupadd
debian/sssd/usr/sbin/sss_usermod" were not uselessly linked against it
(they use none of its symbols).
dpkg-shlibdeps: warning: dependency on librt.so.1 could be avoided if
"debian/sssd/usr/sbin/sss_groupdel
debian/sssd/usr/lib/sssd/libsss_ldap.so.1.0.0
debian/sssd/usr/lib/sssd/libsss_proxy.so.1.0.0
debian/sssd/usr/lib/sssd/sssd/sssd_nss debian/sssd/usr/sbin/sssd
debian/sssd/usr/sbin/sss_userdel debian/sssd/usr/lib/sssd/sssd/sssd_be
debian/sssd/usr/lib/sssd/sssd/sssd_pam
debian/sssd/usr/lib/sssd/sssd/sssd_dp debian/sssd/usr/sbin/sss_useradd
debian/sssd/usr/lib/ldb/memberof.so
debian/sssd/usr/lib/krb5/plugins/libkrb5/sssd_krb5_locator_plugin.so
debian/sssd/usr/sbin/sss_groupmod debian/sssd/usr/sbin/sss_groupadd
debian/sssd/usr/sbin/sss_usermod
debian/sssd/usr/lib/sssd/libsss_krb5.so.1.0.0" were not uselessly
linked against it (they use none of its symbols).
dpkg-shlibdeps: warning: dependency on libplc4.so could be avoided if
"debian/sssd/usr/sbin/sss_groupdel
debian/sssd/usr/lib/sssd/sssd/sssd_nss debian/sssd/usr/sbin/sssd
debian/sssd/usr/sbin/sss_userdel debian/sssd/usr/lib/sssd/sssd/sssd_be
debian/sssd/usr/lib/sssd/sssd/sssd_pam
debian/sssd/usr/lib/sssd/sssd/sssd_dp debian/sssd/usr/sbin/sss_useradd
debian/sssd/usr/sbin/sss_groupmod debian/sssd/usr/sbin/sss_groupadd
debian/sssd/usr/sbin/sss_usermod" were not uselessly linked against it
(they use none of its symbols).
dpkg-shlibdeps: warning: dependency on libplds4.so could be avoided if
"debian/sssd/usr/sbin/sss_groupdel
debian/sssd/usr/lib/sssd/sssd/sssd_nss debian/sssd/usr/sbin/sssd
debian/sssd/usr/sbin/sss_userdel debian/sssd/usr/lib/sssd/sssd/sssd_be
debian/sssd/usr/lib/sssd/sssd/sssd_pam
debian/sssd/usr/lib/sssd/sssd/sssd_dp debian/sssd/usr/sbin/sss_useradd
debian/sssd/usr/sbin/sss_groupmod debian/sssd/usr/sbin/sss_groupadd
debian/sssd/usr/sbin/sss_usermod" were not uselessly linked against it
(they use none of its symbols).
dpkg-shlibdeps: warning: dependency on libnssutil3.so could be avoided
if "debian/sssd/usr/sbin/sss_groupdel
debian/sssd/usr/lib/sssd/sssd/sssd_nss debian/sssd/usr/sbin/sssd
debian/sssd/usr/sbin/sss_userdel debian/sssd/usr/lib/sssd/sssd/sssd_be
debian/sssd/usr/lib/sssd/sssd/sssd_pam
debian/sssd/usr/lib/sssd/sssd/sssd_dp debian/sssd/usr/sbin/sss_useradd
debian/sssd/usr/sbin/sss_groupmod debian/sssd/usr/sbin/sss_groupadd
debian/sssd/usr/sbin/sss_usermod" were not uselessly linked against it
(they use none of its symbols).
dpkg-shlibdeps: warning: dependency on libsmime3.so could be avoided
if "debian/sssd/usr/sbin/sss_groupdel
debian/sssd/usr/lib/sssd/sssd/sssd_nss debian/sssd/usr/sbin/sssd
debian/sssd/usr/sbin/sss_userdel debian/sssd/usr/lib/sssd/sssd/sssd_be
debian/sssd/usr/lib/sssd/sssd/sssd_pam
debian/sssd/usr/lib/sssd/sssd/sssd_dp debian/sssd/usr/sbin/sss_useradd
debian/sssd/usr/sbin/sss_groupmod debian/sssd/usr/sbin/sss_groupadd
debian/sssd/usr/sbin/sss_usermod" were not uselessly linked against it
(they use none of its symbols).
dpkg-shlibdeps: warning: dependency on libk5crypto.so.3 could be
avoided if "debian/sssd/usr/lib/sssd/libsss_krb5.so.1.0.0" were not
uselessly linked against it (they use none of its symbols).
[1]: http://launchpadlibrarian.net/30425717/buildlog_ubuntu-karmic-i386.sssd_0.5…
Could these be avoided somehow?
--
Mathias Gug
Ubuntu Developer http://www.ubuntu.com
Hi,
while testing Stephen's 'only one local domain' patch I found that if
the last configured domain is broken sssd terminates even if there valid
domains available. The following patch will fix this.
bye,
Sumit
These were unintentionally committed binary files. They were used
by the Samba project during cross-compilation, but they serve no
purpose for us.
--
Stephen Gallagher
RHCE 804006346421761
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Recently there has been a lot of activity in Trac surrounding our
support for invoking the legacy shadow-utils tools for managing legacy
files-based domains. This has raised some questions over the utility of
this feature.
First of all, there is an unreasonable amount of code implemented to
handle the logic of determining into which domain we're attempting to
add a user.
Secondly, the legacy local users (provider=files) is the only non-native
backend that we're providing any special handling for. I'm not sure I
see the utility in exerting so much effort supporting a configuration we
hope to be phasing out.
So my proposal is to have the sss_* tools support only the native local
domain in the SSSD (provider=local). By extension, I also propose that
we mandate that a valid config must have exactly one provider=local
domain (it can hold whatever name the administrator desires, but it
should always be there). There should never be more than one, as that
doesn't really make sense and would similarly introduce the complexity
of adding users to the domains.
In summary, I feel that the sssd commandline user and group tools should
manipulate only the SSSD native local users and groups, and all
configurations of the SSSD need to ensure that a native local domain is
present.
Please raise questions and comments in reply to this message.
- --
Stephen Gallagher
RHCE 804006346421761
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkqJpmEACgkQeiVVYja6o6OvHwCgpc6NLUlgj+jFHWTWbpMOj4e4
ilwAn3xDugbXQv71sH14WcSK0PwCUEh2
=6L5u
-----END PGP SIGNATURE-----
Hi,
I've just uploaded an SSSD package to the FreeIPA team PPA [1] to be
tested on Ubuntu Karmic. It builds a snapshot from the git master tree
(via the bzr import of master [2]). The specific Debian packaging is
available from another bzr branch [3].
[1]: https://launchpad.net/~freeipa/+archive/ppa
[2]: https://code.launchpad.net/~vcs-imports/sssd/trunk
[3]: https://code.launchpad.net/~mathiaz/sssd/ubuntu-pkg
My plan is still to try to get 0.5.0 in Karmic. The deadline
(FeatureFreeze) is Thu, August 27th.
I'll try to do an upload on a daily basis to make sure master keeps
building on Karmic. And I think that the Debian packaging is ready. Next
step is to get more testing done on the sssd packages available from the
FreeIPA PPA.
--
Mathias Gug
Ubuntu Developer http://www.ubuntu.com
In the code review of the DP reconnection patch, I noticed a
build-breaking bug which I fixed in-tree and then failed to push to the
upstream tree.
This one-liner fixes the broken build. (Pushed to master under the
one-liner and urgency rules)
--
Stephen Gallagher
RHCE 804006346421761
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
I am working on removing the 'legacy' option.
The idea is to always save data in our cache using the member/memberof
schema and let backends manage how to process incoming data without
forcing all internal code to conform to differences imposed by backends.
I have pushed 7 patches to my personal tree.
Here:
http://fedorapeople.org/gitweb?p=simo/public_git/sssd.git;a=summary
So far it works with my limited testing against the native ldap driver.
Once I have at least briefly tested other backends I'll propose these
patches for inclusion.
Note that this patch set may also fix some existing bugs in the group
enumeration code.
Simo.