uid with @(at) sign
by Stefan Lesicnik
Hi,
I'm hoping someone can help. I am using RHEL 6.1 and trying to use sssd to authenticate to our ldap server.
Our ldap server uses the uid=name@domain as the uid. sssd seems to pass the name part only. Below is the extract from log.
This is generated by running getent passwd stefan(a)lsd.com
Originally I had the issue where the @ part of the search was looking for a specific sssd provider. I changed my domain to lsd.com. This lets me search but as you can see below, passes the filter of uid=stefan and not uid=stefan(a)lsd.com
Thanks in advance,
Stefan
==> slapd trace
Dec 5 12:51:58 ecstasy slapd[15262]: conn=1327 op=4 SRCH base="ou=lsd,ou=users,dc=lsd,dc=co,dc=za" scope=2 deref=0 filter="(&(uid=stefan)(objectClass=posixAccount))"
Dec 5 12:51:58 ecstasy slapd[15262]: conn=1327 op=4 SRCH attr=objectClass uid userPassword uidNumber gidNumber gecos homeDirectory loginShell krbPrincipalName cn modifyTimestamp modifyTimestamp shadowLastChange shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange krbPasswordExpiration pwdAttribute authorizedService accountExpires userAccountControl nsAccountLock
==> sssd_nss.log <==
(Mon Dec 5 12:55:40 2011) [sssd[nss]] [accept_fd_handler] (4): Client connected!
(Mon Dec 5 12:55:40 2011) [sssd[nss]] [sss_cmd_get_version] (5): Received client version [1].
(Mon Dec 5 12:55:40 2011) [sssd[nss]] [sss_cmd_get_version] (5): Offered version [1].
(Mon Dec 5 12:55:40 2011) [sssd[nss]] [nss_cmd_getpwnam] (4): Requesting info for [stefan] from [lsd.com]
(Mon Dec 5 12:55:40 2011) [sssd[nss]] [nss_cmd_getpwnam_search] (4): Requesting info for [stefan(a)lsd.com]
(Mon Dec 5 12:55:40 2011) [sssd[nss]] [sss_dp_send_acct_req_create] (4): Sending request for [lsd.com][4097][1][name=stefan]
==> sssd_lsd.com.log <==
(Mon Dec 5 12:55:40 2011) [sssd[be[lsd.com]]] [be_get_account_info] (4): Got request for [4097][1][name=stefan]
(Mon Dec 5 12:55:40 2011) [sssd[be[lsd.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success
==> sssd_nss.log <==
(Mon Dec 5 12:55:40 2011) [sssd[nss]] [sss_dp_get_reply] (4): Got reply (0, 0, Success) from Data Provider
(Mon Dec 5 12:55:40 2011) [sssd[nss]] [nss_cmd_getpwnam_search] (4): Requesting info for [stefan(a)lsd.com]
==> sssd_lsd.com.log <==
==> sssd_nss.log <==
(Mon Dec 5 12:55:40 2011) [sssd[nss]] [nss_cmd_getpwnam_search] (2): No results for getpwnam call
(Mon Dec 5 12:55:40 2011) [sssd[nss]] [client_recv] (5): Client disconnected!
12 years, 4 months
[PATCH] Allow using Glib for UTF8 support
by Stephen Gallagher
Currently, SSSD only supports using libunistring to manage unicode
strings. There are some platforms out there (such as RHEL 5) that do not
have libunistring available. With this patch, we add an optional flag to
autoconf to allow SSSD to link against Glib and use its unicode
functionality.
12 years, 4 months
IMPORTANT: Your input requested: SSSD LDAP Provider vs Winbind
by Stephen Gallagher
When we originally designed SSSD, we looked at it as a solution for
dealing with LDAP and Kerberos identity and authentication for Linux and
UNIX clients. With our initial approach, we decided to include only
marginal support for Microsoft's Active Directory as a source of user
information (only supporting it when it is enabled for use with
posixAccount and posixGroup object classes).
Our original assumption was that for complicated deployments relying on
Active Directory, users would prefer to continue using Winbind. It has a
very long history and is specifically designed around managing the
peculiarities of Microsoft's LDAP implementation.
Of late, it has become apparent that many users are opting to "jump
ship" from winbind to SSSD for use with Active Directory. This has been
shown by a sharp uptick in community bug reports with Active Directory
servers.
Up until now, our plans around Active Directory have circulated around
including a "Winbind Provider" into SSSD, similar to the LDAP provider
but making use of the original winbind features found in the Samba
project. However, it's beginning to seem like users are expressing an
interest to move AWAY from that solution.
This may result in a change in our strategy going forward. I'm looking
for users to describe to us the reasons why they're choosing SSSD (in
its current incarnation) over winbind. What I'm trying to sort out is
whether there are specific *issues* with winbind that SSSD is solving
for users. In other words, I'm trying to determine whether our decision
to write and support a winbind provider backend is misplaced.
It may be that if SSSD's LDAP provider is offering a significant
advantage over winbind, we will consider dropping (or deferring) our
efforts to integrate winbind and instead put that effort into adding
Active Directory-specific features into the LDAP provider. For example,
we might reprioritize bugs https://fedorahosted.org/sssd/ticket/995 and
https://fedorahosted.org/sssd/ticket/996
So please, share with us your stories for why you prefer SSSD over
winbind and help us choose our direction for SSSD's future.
12 years, 4 months
FC16 - how to get ExecStop= to be executed at shutdown?
by Josh Geisser
Hi all
I succeeded with auto login and auto start of my Virtual Boxes, but could not get them to do a proper shutdown.
Because of the nature of the VM processes I want to send them a proper ACPI shutdown button instead of terminating the process, which is done through my old rc-script.
The VirtualBoxes process are started AFTER X11 is up, but must also be shutdown BEFORE the display-manager is exited.
How do I configure this in the service file?
My /lib/systemd/system/vbox.service:
[Unit]
Description=Virtual Box Machines
After=vboxdrv.service network.target display-manager.service
[Service]
Type=forking
ExecStart=/home/vmuser/./rc.virtualboxes start | /usr/bin/logger
ExecStop=/home/vmuser/./rc.virtualboxes stop | /usr/bin/logger
[Install]
WantedBy=graphical.target
Cheers & thx
Josh
--
----
ASG at hnet
12 years, 4 months
RFC: sudo cache behaviour
by Jakub Hrozek
Hi,
As we work on the Sudo integration with Pavel, I'm thinking about how
should we handle our cache.
On one hand, I think our cache should be complete and possibly up to date
to allow seamless offline operation. In the first prototype we have now,
we just download the whole tree during every request. That's not going
to scale, obviously. There can be many rules and downloading them all can
get expensive.
I think we can use the following mechanism:
1) the backend would schedule a periodic task to download all rules,
much like the current enumeration task. There may be an option to
fine tune how often should the task start.
2) when a request comes, we would update the cache that affects the
user only(*). We keep an in-memory timeout per user so that subsequent
requests from the same user are handled fast.
Does that sound OK?
* even native sudo only searches for
"(|(sudoUser=ALL)(sudoUser=username)(sudoUser=%group1)(sudoUser=%group2))"
so we can limit the online update the same way
12 years, 4 months
