10:27 a.m.
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/KerberosPrincipalMappingToP...
>
>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
>sssd-devel(a)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(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:
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.