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/KerberosPrincipalMappingToProx...
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@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@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@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@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@redhat.com
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/KerberosPrincipalMappingToProx...
For your convenience, the text of the design page is also copied below:
= Mapping Proxy ID provider names to Kerberos principals =
Related ticket(s):
=== 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@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 ===
- Prepare a Kerberos KDC, add a user principal (`juser@EXAMPLE.COM`)
- Add a local user using `useradd` with name that differs from Kerberos principal in the name portion. (`joe`)
- Configure SSSD with `id_provider=proxy` with `proxy_lib_name=files` and `auth_provider=krb5` pointing to our test KDC
- Attempt to authenticate using a PAM service. The authentication should fail and the logs would show authentication as `joe@EXAMPLE.COM`
- Set `krb5_map_user` to `joe:juser` and restart SSSD.
- Authenticate again. This time, authentication should succeed and the user's klist output should list `juser@EXAMPLE.COM`. The `id(1)` output should still list `joe`, though.
- Test that Kerberos ticket renewals still work
- Test that delayed kinit still works.
=== Authors ===
- Jakub Hrozek jhrozek@redhat.com
sssd-devel mailing list sssd-devel@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. 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?
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/KerberosPrincipalMappingToProx...
For your convenience, the text of the design page is also copied below:
= Mapping Proxy ID provider names to Kerberos principals =
Related ticket(s):
=== 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@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 ===
- Prepare a Kerberos KDC, add a user principal (`juser@EXAMPLE.COM`)
- Add a local user using `useradd` with name that differs from Kerberos principal in the name portion. (`joe`)
- Configure SSSD with `id_provider=proxy` with `proxy_lib_name=files` and `auth_provider=krb5` pointing to our test KDC
- Attempt to authenticate using a PAM service. The authentication should fail and the logs would show authentication as `joe@EXAMPLE.COM`
- Set `krb5_map_user` to `joe:juser` and restart SSSD.
- Authenticate again. This time, authentication should succeed and the user's klist output should list `juser@EXAMPLE.COM`. The `id(1)` output should still list `joe`, though.
- Test that Kerberos ticket renewals still work
- Test that delayed kinit still works.
=== Authors ===
- Jakub Hrozek jhrozek@redhat.com
sssd-devel mailing list sssd-devel@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@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.
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/KerberosPrincipalMappingToProx...
For your convenience, the text of the design page is also copied below:
= Mapping Proxy ID provider names to Kerberos principals =
Related ticket(s):
=== 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@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 ===
- Prepare a Kerberos KDC, add a user principal (`juser@EXAMPLE.COM`)
- Add a local user using `useradd` with name that differs from Kerberos principal in the name portion. (`joe`)
- Configure SSSD with `id_provider=proxy` with `proxy_lib_name=files` and `auth_provider=krb5` pointing to our test KDC
- Attempt to authenticate using a PAM service. The authentication should fail and the logs would show authentication as `joe@EXAMPLE.COM`
- Set `krb5_map_user` to `joe:juser` and restart SSSD.
- Authenticate again. This time, authentication should succeed and the user's klist output should list `juser@EXAMPLE.COM`. The `id(1)` output should still list `joe`, though.
- Test that Kerberos ticket renewals still work
- Test that delayed kinit still works.
=== Authors ===
- Jakub Hrozek jhrozek@redhat.com
sssd-devel mailing list sssd-devel@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@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@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.
On Tue, Apr 21, 2015 at 06:24:37PM +0200, Pavel Reichl wrote:
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.
Thanks! Looking forward to the patches. I know there are some volunteers who'd like to test :-)
sssd-devel@lists.fedorahosted.org