[SSSD] Design discussion: Mapping user names of proxy users onto Kerberos principals

Pavel Reichl preichl at redhat.com
Tue Apr 21 16:24:37 UTC 2015


On 12/04/2014 05:27 PM, Jakub Hrozek wrote:
> On Thu, Dec 04, 2014 at 10:31:42AM -0500, Dmitri Pal wrote:
>> On 12/04/2014 06:55 AM, Jakub Hrozek wrote:
>>> Hi,
>>>
>>> we talked about implementing ticket #2509 with Pavel in person, but it
>>> would be nice to see if other other developers agree before all the code
>>> is written :-)
>>>
>>> The design page is here:
>>>      https://fedorahosted.org/sssd/wiki/DesignDocs/KerberosPrincipalMappingToProxyUsers
>>>
>>> For your convenience, the text of the design page is also copied below:
>>>
>>> = Mapping Proxy ID provider names to Kerberos principals =
>>>
>>> Related ticket(s):
>>>   * https://fedorahosted.org/sssd/ticket/2509
>>>
>>> === Problem statement ===
>>> Some users are migrating to SSSD from a legacy configuration that consisted
>>> of a traditional UNIX user stored in `/etc/passwd` and managing their
>>> Kerberos tickets either with the use of some GUI tool or just command-line
>>> `kinit`. While these users can use SSSD by configuring the `id_provider`
>>> proxy, very often the name of their UNIX user is different from the name
>>> of their company-wide Kerberos credentials.
>>>
>>> This feature helps the above use-case by mapping their UNIX user name to
>>> the Kerberos principal name.
>>>
>>> === Use cases ===
>>> Joe User has a company laptop where his UNIX user has been traditionally
>>> named `joe`. At the same time, his company Kerberos principal is called
>>> `juser at EXAMPLE.COM`. Joe would like to start using SSSD to leverage
>>> features like offline kinit without having to rename his UNIX user and
>>> chown all his local files to the corporate user ID.
>>>
>>> === Overview of the solution ===
>>> The Kerberos provider will acquire a new option that describes how are the
>>> user names from the ID provider mapped onto the user part of the Kerberos
>>> principal. The user would then add the appropriate mapping to the `domain`
>>> section of `sssd.conf`.
>>>
>>> === Implementation details ===
>>> A new option `krb5_map_user` would be added to the Kerberos auth code. This
>>> option would have form similar to how we map the LDAP extra attributes,
>>> that is `local_name:krb5_name`. When mapping exists for the user who
>>> is authenticating, the krb5_auth module would use that user name for
>>> calls like `find_or_guess_upn` instead of `pd->name`. We should consider
>>> whether to keep using `pd->name` or introduce another attribute to the
>>> `krb5_child_req` structure.
>>>
>>> === Configuration changes ===
>>> A new configuration option tentatively called `krb5_map_user` would be
>>> added. This option is unset by default, which means whatever user name
>>> the ID provider stores will be used.
>>>
>>> === How To Test ===
>>> 1. Prepare a Kerberos KDC, add a user principal (`juser at EXAMPLE.COM`)
>>> 1. Add a local user using `useradd` with name that differs from
>>>     Kerberos principal in the name portion. (`joe`)
>>> 1. Configure SSSD with `id_provider=proxy` with `proxy_lib_name=files`
>>>     and `auth_provider=krb5` pointing to our test KDC
>>> 1. Attempt to authenticate using a PAM service. The authentication
>>>     should fail and the logs would show authentication as `joe at EXAMPLE.COM`
>>> 1. Set `krb5_map_user` to `joe:juser` and restart SSSD.
>>> 1. Authenticate again. This time, authentication should succeed and the
>>>     user's klist output should list `juser at EXAMPLE.COM`. The `id(1)` output
>>>     should still list `joe`, though.
>>> 1. Test that Kerberos ticket renewals still work
>>> 1. Test that delayed kinit still works.
>>>
>>> === Authors ===
>>> * Jakub Hrozek <jhrozek at redhat.com>
>>> _______________________________________________
>>> sssd-devel mailing list
>>> sssd-devel at lists.fedorahosted.org
>>> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
>> OK, this indeed solves a broader use case as I hoped.
>> Questions:
>> a) How it is related to .k5login? I think we already have some equivalent of
>> the .k5login functionality in SSSD.
>> Do I get it that k5login solves the problem of mapping Kerberos principal to
>> local user while the request is to map local user to kerberos principal.
> Yes, .k5login tells you that i.e whoever has ticket for jhrozek at REDHAT.COM
> can log in as root on a system.
>
>> b) Why just proxy provider? If local user can be mapped to remote user that
>> means that you need to take a remote user and have a local POSIX overwrite.
>> I mean it should be more generic:
>> local_user_overwrite=local_user:remote_user.
>> That would mean:
>> - when I authenticate using local user use remote_user instead for any
>> authentication provider
>> - when data from central server comes back for remote_user regardless of the
>> identity provider it should be overwritten by data from local file
>> Something along those lines. Does that make sense?
> The functionality is generic, but I guess the design page doesn't
> describe it as such. As designed, the option would overwrite
> SYSDB_NAME (irrespective of the ID provider) with the configured name
> when constructing the principal.
>
> I agree that the design page only talks about the proxy provider since
> that would be the primary use case. I've added a note.
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
Thanks for the design, I have a working prototype based on it.  I'll 
just need to clean and properly test the patch before posting it on the 
list.



More information about the sssd-devel mailing list