On Thu, Dec 04, 2014 at 10:31:42AM -0500, Dmitri Pal wrote:
> On 12/04/2014 06:55 AM, Jakub Hrozek wrote:
>> 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:
>> 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(a)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(a)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(a)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(a)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(a)redhat.com>
>> sssd-devel mailing list
> OK, this indeed solves a broader use case as I hoped.
> 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(a)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:
> 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
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