[PATCH] Cherry-pick Stef's sbus_request patches to sssd-1-11
by Jakub Hrozek
Hi,
the attached patchset cherry-picks the sbus_request patches to
sssd-1-11. As with the previous set I sent, I left the conflict messages
in the commit headers. There were only two conflicts, one in the
Makefile (tests again) and one trivial in #include section of one of the
sbus source files.
9 years, 6 months
[PATCH] Cherry-pick Stef's sbus_codegen to sssd-1-11
by Jakub Hrozek
Hi,
attached are cherry-picked patches that implement Stef's sbus_codegen.
Only the first patch in the series had to be rebased in a very trivial
way:
diff --cc Makefile.am
index 8d92326,d7e6243..0000000
--- a/Makefile.am
+++ b/Makefile.am
@@@ -133,7 -141,9 +133,13 @@@ if HAVE_CHEC
debug-tests \
ipa_hbac-tests \
sss_idmap-tests \
++<<<<<<< HEAD
+ responder_socket_access-tests
++=======
+ responder_socket_access-tests \
+ safe-format-tests \
+ sbus_codegen_tests
++>>>>>>> b699c4d... sbus: Add meta data structures and code generator
if BUILD_SSH
non_interactive_check_based_tests += sysdb_ssh-tests
For the reviewer's convenience I left the Conflicts: messages in the commit
header so it's clearly visible which part of the patch had to be amended.
9 years, 6 months
RFC: Backporting the SBUS changes to 1.11
by Jakub Hrozek
Hi,
As you might have noticed already, we're pushing 1.11 and its AD related
improvements to older releases as well, including RHEL-6. These
platforms are supposed to be /stable/.
I've been thinking about how exactly should we backport all the sbus
changes Stef and me did. While especially Stef's coding quality
standards are pretty high and most of the new code is covered with unit
tests, I'm still a bit nervous about changing such a low-level component
in a stable release.
So I was thinking about an alternative -- only import the new sbus code
into the src/responders/ifp directory in 1.11. The protocol the
processes use to talk to one another has not changed and this way, only
the IFP responder would be affected by any bugs in the sbus changes.
Comments?
9 years, 6 months
[DESIGN] Allow Kerberos Principals in getpwnam() calls
by Sumit Bose
Hi,
I have summarized a thread on this list and added some additional
information on
https://fedorahosted.org/sssd/wiki/DesignDocs/NSSWithKerberosPrincipal
For your convenience the text can be found below as well. Comments and
suggestions are welcome.
bye,
Sumit
= Allow Kerberos Principals in getpwnam() calls =
Related ticket(s):
* [https://fedorahosted.org/sssd/ticket/1835 RFE Implement localauth
* plugin for MIT krb5 1.12]
* [https://fedorahosted.org/sssd/ticket/1749 RFE Allow email-address in
* ldap_user_principal]
== Problem Statement ==
When using Kerberos/GSSAPI authentication for a service running on a
Linux host strictly speaking not a POSIX user of the Linux system is
authenticated but a Kerberos principal. I.e. authentication is
successful for every Kerberos principal with a valid ticket for the
service running on the Linux host. This is done intentional to keep
Kerberos independent of the operating system of the host. But it creates
the problem of mapping Kerberos principals to POSIX users.
Basic mappings are integrated in the MIT Kerberos library. By default
the realm part of the Kerberos principal is stripped off and what
remains is considered as a POSIX user name. The administrator can
enhance this by adding some minimal regular-expression operations in
/etc/krb5.conf. Addionally the user can create a .k5login file in his
home directory and add all Kerberos principals which should be allowed
to log in with his identity. All those methods do not scale in
environments with multiple realm and cross-realm trust.
To allow more advance mapping schemes a plugin interface was introduced
in MIT Kerberos version 1.12.
If the Kerberos principal is available SSSD will store it in its cache
in the related user object. The Kerberos principal can be retrieved by
looking it up in the central IdM system (LDAP/IPA/AD). If the Kerberos
principal is not available but Kerberos authentication is configured
SSSD will guess it by adding the configured realm or domain name to the
POSIX user name. If authentication is successful with this principal it
is stored in the cache as well.
A plugin which looks up the Kerberos principal in SSSD and gets the
POSIX user entry back would provide a reliable mapping and scale across
multiple realms and trusts because SSSD supports it.
= Overview of the Solution =
== Implementation details ==
Currently the NSS responder expects that the argument of the getpwnam()
call is a user name, either fully qualified or the short version without
a domain name. The name is evaluated with the help of regular expression
and split into a user and a domain component. By default the '@'
character is one of the characters to separate the user and to domain
component in a fully qualified user name. This collides with the usage
of the '@' character in Kerberos principals, because here it is used to
separate the user and the realm component.
One way to solve this is to introduce a special prefix tag, e.g.
':princ:' to indicate that the reminder of the string should be
considered as a Kerberos principal and not be split as fully qualified
user names. While this would work for the localauth plugin use-case
there are other potential use-cases where this would not be possible.
E.g if SSSD should allow AD user to use their UPN (see
[http://technet.microsoft.com/en-us/library/cc739093(v=WS.10).aspx
http://technet.microsoft.com/en-us/library/cc739093(v=WS.10).aspx] for
details). This UPN is build by joining the user logon name and a UPN
suffix with an '@' character. I think it cannot be expected from the AD
users to add a prefix to this name and pam_sss cannot do it either
because it does not know it is a fully qualified name or a UPN.
Especially with the second use-case in my me should process the argument
of getpwnam() like a fully qualified user name first. If no matching
user was found during this pass SSSD can take the orginal input, check
if it contains an '@' character and search the configured backends for a
matching Kerberos principal or UPN. It has to be noted that in theory
there might be a user with the fully qualified name
{{{abc(a)domain.name}}} and the Kerberos principal {{{def(a)domain.com}}}
and a user with the fully qualified name {{{def(a)domain.name}}} and the
Kerberos principal {{{abc(a)domain.name}}}. In this case
getpwnam("{{{abc(a)domain.name}}}") will always return the entry for the
user with the fully qualified name {{{abc(a)domain.name}}} even if the
input was meant as Kerberos principal. This is even possible with Active
Directory, i.e. the pre-Windows 2000 name and the user logon name of
different users can be the same. I would say that those cases are rare
and can be considered as broken configuration.
If the NSS responder decides that the given argument should be
considered as a Kerberos principal and was not able to find a matching
principal in the cache it can iterate over the configured backends and
send a GETACCOUNTINFO request for a user with a new filter type, e.g.
BE_FILTER_PRINCIPAL. The LDAP based ID backend which wants to support
this new filter type can process it like a any user request but have to
use an appropriate search filter.
== Additional notes ==
The SSSD cache knows two attributes for principals "userPrincipalName"
and "canonicalUserPrincipalName". The first is used to save the data
read from the LDAP server. The second is used if the TGT contains a
different principal than the one used to request the TGT, i.e. if the
original principal was an alias. While search principals in the cache
both should be respected. Currently "userPrincipalName" is already
declared CASE_INSENSITIVE for searched in the cache.
"canonicalUserPrincipalName" should be declared the same way to make
searches consistent.
== How to test ==
To make sure that a {{{getent passwd user(a)dmain.name}}} search for the
Kerberos principal {{{user(a)domain.name}}} and not for a fully qualified
name the domain name in sssd.conf should differ from the realm name in
the principal. Probably the easiest configuration is to use the ldap ID
provider and make sure the targeted LDAP server has a Kerberos principal
attrbitute set for the users and the ldap_user_principal option points
to the corresponding attribute name.
{{{
...
[domain/default]
id_provider = ldap
ldap_user_principal = krbPrincipalName
...
}}}
Now the fully qualified names end with '@default' while the Kerberos
principal are defined by the LDAP entries. E.g. if there is a user
'testabc' with the principal {{{testabc(a)MY.REALM}}} the command
{{{getent passwd testabc@default}}} will return the POSIX user entry
searched with the fully qualified name. {{{getent passwd
testabc(a)MY.REALM}}} will return the same entry but now search with the
Kerberos principal.
=== Author(s) ===
Sumit Bose <sbose(a)redhat.com>
9 years, 6 months
