Re: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts
On Tue, May 28, 2013 at 02:50:59PM +0300, Alexander Bokovoy wrote: Hi, http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts === CLI === The feature is not directly exposed in CLI. IPA idrange management is expanded to specify idrange type (IPA local, AD trust, AD with winsync, IPA trust, ..) to affect the way how AD users SIDs are mapped to POSIX IDs. Hi, currently with algorithmic mapping we use user-private groups for all trusted user. This is in agreement with the defaults for IPA users and also matches with AD's RID handling because a single namespace for UIDs and GIDs is forced this way. When adding support for UIDs and GIDs stored in AD we cannot do this anymore because AD (correctly) treats POSIX UIDs and GIDs as separate name spaces. As a consequence SSSD has to treat algorithmic mapping and IDs-in-AD mapping differently with respect to user private groups. My question is, shall SSSD implicitly do the right thing based on the type of the idrange, or shall there be an extra attribute in the idrange object which explicitly says if the range has user private groups or not? I think it is not needed because for both current mappings there is only one choice but maybe someone can think of a reason for such an attribute. bye, Sumit ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts
On Fri, 31 May 2013, Simo Sorce wrote: On Fri, 2013-05-31 at 10:35 -0400, Rob Crittenden wrote: Simo Sorce wrote: On Fri, 2013-05-31 at 16:35 +0300, Alexander Bokovoy wrote: On Fri, 31 May 2013, Simo Sorce wrote: On Fri, 2013-05-31 at 10:54 +0300, Alexander Bokovoy wrote: On Thu, 30 May 2013, Dmitri Pal wrote: [...] For Lunix and older SSSD version we in fact have a problem. What I want to avoid is to have to define procedures and patches for all ^^ ? the clients. However if you use ipa-client-install it would configure sssd the old way. How to make it configured the new way? Manually? This is error prone and people will be reluctant to reconfigure SSSD. Automatically? Means patches to all the versions of the clients. How we are going to deal with the huge test matrix? I think rolling out patches to old sssd versions is not a good idea and I think we won't have the time to prepare all the needed patches in a reasonable time-frame. For SSSD versions which do not allow multiple search bases (1.5 and 1.6) I would suggest to add a new domain section for the AD user with LDAP and Kerberos provider. This would allow IPA users to works as before and add the AD users to the client. Maybe this would also be a better solution for the other SSSD versions instead of multiple search bases, at least it's a solution for all versions. Since we have the python config API for SSSD the needed changes to the sssd.conf might be scriptable with a reasonable effort. Maybe this can be added to ipa-client-install with a new option like --enable-legacy-trust-support which can add the news section to existing configuration or include it for new installations? Bigger question is what is simpler: write configuration instructions or modify/provide additional script for old SSSD? Remeber that trusts with AD are most likely established when IPA clients are already rolled out. Changing ipa-client-install is not helpful for this case since the clients are already there. Perhaps a better approach would be documentation for non-SSSD case and a simple snippet that can be run alone or in use with puppet/etc to deploy massively. The snippet would use SSSDConfig Python API to add needed modifications to the clients' SSSD configuration. We can even extend IPA server tools to allow generating such snippets based on the trusts configuration. After all, we do have control over IPA server in such cases. I have updated wiki page with discussed ideas. Sorry but this is not enough. I do not see a discussion the design about the client side solutuon procedure. I am looking for a session that would contain a table (or like): -- | Type/Version of the client | Action| -- | Solaris/HP-UX/AIX (non sssd) | Configure manually to recognize AD as | || a domain following following steps ...| -- | Clients that have SSSD | If the client is already installed| | before 1.9 | and configured do X | || If it is a fresh install of the | || client do Y | -- | SSSD 1.9 and later | Use the following ipa-client-install | || flags XYZ and/or authconfig command | || ABC | -- Can something like this be added to wiki and corresponding tickets to provide a testable replacements for XYZ above be filed in trac? I've added more, including three tickets to cover specific configurations. Unfortunately, we have limits in multiple search bases approach by the commercial UNIX vendors since their LDAP modules do not support multiple search bases. For all of those platforms there is PADL pam_ldap available which can be used for the same purpose. If we still want to support native pam_ldap on Solaris (which don't work with multiple search bases), we'd have to merge LDAP trees. Alexander, in my initial proposal I said that trusted users should be put in the same tree as compat users, it was exactly to address this problem. We do not need to cause more problems by using multiple search trees IMO. Ok, since I wanted to re-use slapi-nis anyway, this only means adding one more config attribute to slapi-nis configuration that will ask it to look into NSS in addition to the main query. In which order these queries should be performed? first to LDAP then NSS or first to NSS then to LDAP? I guess the
Re: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts
On Mon, Jun 03, 2013 at 03:32:05PM +0200, Sumit Bose wrote: On Tue, May 28, 2013 at 02:50:59PM +0300, Alexander Bokovoy wrote: Hi, http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts === CLI === The feature is not directly exposed in CLI. IPA idrange management is expanded to specify idrange type (IPA local, AD trust, AD with winsync, IPA trust, ..) to affect the way how AD users SIDs are mapped to POSIX IDs. Hi, currently with algorithmic mapping we use user-private groups for all trusted user. This is in agreement with the defaults for IPA users and also matches with AD's RID handling because a single namespace for UIDs and GIDs is forced this way. When adding support for UIDs and GIDs stored in AD we cannot do this anymore because AD (correctly) treats POSIX UIDs and GIDs as separate name spaces. As a consequence SSSD has to treat algorithmic mapping and IDs-in-AD mapping differently with respect to user private groups. My question is, shall SSSD implicitly do the right thing based on the type of the idrange, or shall there be an extra attribute in the idrange object which explicitly says if the range has user private groups or not? I think it is not needed because for both current mappings there is only one choice but maybe someone can think of a reason for such an attribute. We discussed this a bit and came to the following agreement: - no extra attribute is needed - for all idranges type where IPA is assigning the ID user-private groups will be used (local IPA users, algorithmic mappings) - for all idranges where the IDs are managed by external sources we use what we get bye, Sumit bye, Sumit ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts
On Thu, 30 May 2013, Dmitri Pal wrote: [...] For Lunix and older SSSD version we in fact have a problem. What I want to avoid is to have to define procedures and patches for all ^^ ? the clients. However if you use ipa-client-install it would configure sssd the old way. How to make it configured the new way? Manually? This is error prone and people will be reluctant to reconfigure SSSD. Automatically? Means patches to all the versions of the clients. How we are going to deal with the huge test matrix? I think rolling out patches to old sssd versions is not a good idea and I think we won't have the time to prepare all the needed patches in a reasonable time-frame. For SSSD versions which do not allow multiple search bases (1.5 and 1.6) I would suggest to add a new domain section for the AD user with LDAP and Kerberos provider. This would allow IPA users to works as before and add the AD users to the client. Maybe this would also be a better solution for the other SSSD versions instead of multiple search bases, at least it's a solution for all versions. Since we have the python config API for SSSD the needed changes to the sssd.conf might be scriptable with a reasonable effort. Maybe this can be added to ipa-client-install with a new option like --enable-legacy-trust-support which can add the news section to existing configuration or include it for new installations? Bigger question is what is simpler: write configuration instructions or modify/provide additional script for old SSSD? Remeber that trusts with AD are most likely established when IPA clients are already rolled out. Changing ipa-client-install is not helpful for this case since the clients are already there. Perhaps a better approach would be documentation for non-SSSD case and a simple snippet that can be run alone or in use with puppet/etc to deploy massively. The snippet would use SSSDConfig Python API to add needed modifications to the clients' SSSD configuration. We can even extend IPA server tools to allow generating such snippets based on the trusts configuration. After all, we do have control over IPA server in such cases. I have updated wiki page with discussed ideas. Sorry but this is not enough. I do not see a discussion the design about the client side solutuon procedure. I am looking for a session that would contain a table (or like): -- | Type/Version of the client | Action| -- | Solaris/HP-UX/AIX (non sssd) | Configure manually to recognize AD as | || a domain following following steps ...| -- | Clients that have SSSD | If the client is already installed| | before 1.9 | and configured do X | || If it is a fresh install of the | || client do Y | -- | SSSD 1.9 and later | Use the following ipa-client-install | || flags XYZ and/or authconfig command | || ABC | -- Can something like this be added to wiki and corresponding tickets to provide a testable replacements for XYZ above be filed in trac? I've added more, including three tickets to cover specific configurations. Unfortunately, we have limits in multiple search bases approach by the commercial UNIX vendors since their LDAP modules do not support multiple search bases. For all of those platforms there is PADL pam_ldap available which can be used for the same purpose. If we still want to support native pam_ldap on Solaris (which don't work with multiple search bases), we'd have to merge LDAP trees. #3670 [RFE] tool to create configurations for old legacy clients for trusts https://fedorahosted.org/freeipa/ticket/3670 #3671 add support for SSSD 1.5-1.8 configurations to ipa-advise-client https://fedorahosted.org/freeipa/ticket/3671 #3672 add support for PADL pam_ldap/nss_ldap configurations to ipa-advise-client https://fedorahosted.org/freeipa/ticket/3672 ipa-advise-client tool would look up existing IPA server configuration and decide how should look sample configuration for the specified case. It will generate a script that will output needed configuration files (or their snippets) or commands that should be executed on the client side. The reason for this indirection is to allow greater flexibility in future, like being able to check PAM configuration at the client side before recommending changes (or run authconfig). -- / Alexander Bokovoy
Re: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts
On Fri, 2013-05-31 at 10:54 +0300, Alexander Bokovoy wrote: On Thu, 30 May 2013, Dmitri Pal wrote: [...] For Lunix and older SSSD version we in fact have a problem. What I want to avoid is to have to define procedures and patches for all ^^ ? the clients. However if you use ipa-client-install it would configure sssd the old way. How to make it configured the new way? Manually? This is error prone and people will be reluctant to reconfigure SSSD. Automatically? Means patches to all the versions of the clients. How we are going to deal with the huge test matrix? I think rolling out patches to old sssd versions is not a good idea and I think we won't have the time to prepare all the needed patches in a reasonable time-frame. For SSSD versions which do not allow multiple search bases (1.5 and 1.6) I would suggest to add a new domain section for the AD user with LDAP and Kerberos provider. This would allow IPA users to works as before and add the AD users to the client. Maybe this would also be a better solution for the other SSSD versions instead of multiple search bases, at least it's a solution for all versions. Since we have the python config API for SSSD the needed changes to the sssd.conf might be scriptable with a reasonable effort. Maybe this can be added to ipa-client-install with a new option like --enable-legacy-trust-support which can add the news section to existing configuration or include it for new installations? Bigger question is what is simpler: write configuration instructions or modify/provide additional script for old SSSD? Remeber that trusts with AD are most likely established when IPA clients are already rolled out. Changing ipa-client-install is not helpful for this case since the clients are already there. Perhaps a better approach would be documentation for non-SSSD case and a simple snippet that can be run alone or in use with puppet/etc to deploy massively. The snippet would use SSSDConfig Python API to add needed modifications to the clients' SSSD configuration. We can even extend IPA server tools to allow generating such snippets based on the trusts configuration. After all, we do have control over IPA server in such cases. I have updated wiki page with discussed ideas. Sorry but this is not enough. I do not see a discussion the design about the client side solutuon procedure. I am looking for a session that would contain a table (or like): -- | Type/Version of the client | Action| -- | Solaris/HP-UX/AIX (non sssd) | Configure manually to recognize AD as | || a domain following following steps ...| -- | Clients that have SSSD | If the client is already installed| | before 1.9 | and configured do X | || If it is a fresh install of the | || client do Y | -- | SSSD 1.9 and later | Use the following ipa-client-install | || flags XYZ and/or authconfig command | || ABC | -- Can something like this be added to wiki and corresponding tickets to provide a testable replacements for XYZ above be filed in trac? I've added more, including three tickets to cover specific configurations. Unfortunately, we have limits in multiple search bases approach by the commercial UNIX vendors since their LDAP modules do not support multiple search bases. For all of those platforms there is PADL pam_ldap available which can be used for the same purpose. If we still want to support native pam_ldap on Solaris (which don't work with multiple search bases), we'd have to merge LDAP trees. Alexander, in my initial proposal I said that trusted users should be put in the same tree as compat users, it was exactly to address this problem. We do not need to cause more problems by using multiple search trees IMO. Simo. #3670 [RFE] tool to create configurations for old legacy clients for trusts https://fedorahosted.org/freeipa/ticket/3670 #3671 add support for SSSD 1.5-1.8 configurations to ipa-advise-client https://fedorahosted.org/freeipa/ticket/3671 #3672 add support for PADL pam_ldap/nss_ldap configurations to ipa-advise-client https://fedorahosted.org/freeipa/ticket/3672 ipa-advise-client tool would look up existing IPA server configuration and decide how should
Re: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts
On Fri, 31 May 2013, Simo Sorce wrote: On Fri, 2013-05-31 at 10:54 +0300, Alexander Bokovoy wrote: On Thu, 30 May 2013, Dmitri Pal wrote: [...] For Lunix and older SSSD version we in fact have a problem. What I want to avoid is to have to define procedures and patches for all ^^ ? the clients. However if you use ipa-client-install it would configure sssd the old way. How to make it configured the new way? Manually? This is error prone and people will be reluctant to reconfigure SSSD. Automatically? Means patches to all the versions of the clients. How we are going to deal with the huge test matrix? I think rolling out patches to old sssd versions is not a good idea and I think we won't have the time to prepare all the needed patches in a reasonable time-frame. For SSSD versions which do not allow multiple search bases (1.5 and 1.6) I would suggest to add a new domain section for the AD user with LDAP and Kerberos provider. This would allow IPA users to works as before and add the AD users to the client. Maybe this would also be a better solution for the other SSSD versions instead of multiple search bases, at least it's a solution for all versions. Since we have the python config API for SSSD the needed changes to the sssd.conf might be scriptable with a reasonable effort. Maybe this can be added to ipa-client-install with a new option like --enable-legacy-trust-support which can add the news section to existing configuration or include it for new installations? Bigger question is what is simpler: write configuration instructions or modify/provide additional script for old SSSD? Remeber that trusts with AD are most likely established when IPA clients are already rolled out. Changing ipa-client-install is not helpful for this case since the clients are already there. Perhaps a better approach would be documentation for non-SSSD case and a simple snippet that can be run alone or in use with puppet/etc to deploy massively. The snippet would use SSSDConfig Python API to add needed modifications to the clients' SSSD configuration. We can even extend IPA server tools to allow generating such snippets based on the trusts configuration. After all, we do have control over IPA server in such cases. I have updated wiki page with discussed ideas. Sorry but this is not enough. I do not see a discussion the design about the client side solutuon procedure. I am looking for a session that would contain a table (or like): -- | Type/Version of the client | Action| -- | Solaris/HP-UX/AIX (non sssd) | Configure manually to recognize AD as | || a domain following following steps ...| -- | Clients that have SSSD | If the client is already installed| | before 1.9 | and configured do X | || If it is a fresh install of the | || client do Y | -- | SSSD 1.9 and later | Use the following ipa-client-install | || flags XYZ and/or authconfig command | || ABC | -- Can something like this be added to wiki and corresponding tickets to provide a testable replacements for XYZ above be filed in trac? I've added more, including three tickets to cover specific configurations. Unfortunately, we have limits in multiple search bases approach by the commercial UNIX vendors since their LDAP modules do not support multiple search bases. For all of those platforms there is PADL pam_ldap available which can be used for the same purpose. If we still want to support native pam_ldap on Solaris (which don't work with multiple search bases), we'd have to merge LDAP trees. Alexander, in my initial proposal I said that trusted users should be put in the same tree as compat users, it was exactly to address this problem. We do not need to cause more problems by using multiple search trees IMO. Ok, since I wanted to re-use slapi-nis anyway, this only means adding one more config attribute to slapi-nis configuration that will ask it to look into NSS in addition to the main query. In which order these queries should be performed? first to LDAP then NSS or first to NSS then to LDAP? I guess the answer depends on specific setup -- if all your users in AD, you'd like to look at them first. -- / Alexander Bokovoy ___ Freeipa-devel mailing list
Re: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts
On Fri, 2013-05-31 at 16:35 +0300, Alexander Bokovoy wrote: On Fri, 31 May 2013, Simo Sorce wrote: On Fri, 2013-05-31 at 10:54 +0300, Alexander Bokovoy wrote: On Thu, 30 May 2013, Dmitri Pal wrote: [...] For Lunix and older SSSD version we in fact have a problem. What I want to avoid is to have to define procedures and patches for all ^^ ? the clients. However if you use ipa-client-install it would configure sssd the old way. How to make it configured the new way? Manually? This is error prone and people will be reluctant to reconfigure SSSD. Automatically? Means patches to all the versions of the clients. How we are going to deal with the huge test matrix? I think rolling out patches to old sssd versions is not a good idea and I think we won't have the time to prepare all the needed patches in a reasonable time-frame. For SSSD versions which do not allow multiple search bases (1.5 and 1.6) I would suggest to add a new domain section for the AD user with LDAP and Kerberos provider. This would allow IPA users to works as before and add the AD users to the client. Maybe this would also be a better solution for the other SSSD versions instead of multiple search bases, at least it's a solution for all versions. Since we have the python config API for SSSD the needed changes to the sssd.conf might be scriptable with a reasonable effort. Maybe this can be added to ipa-client-install with a new option like --enable-legacy-trust-support which can add the news section to existing configuration or include it for new installations? Bigger question is what is simpler: write configuration instructions or modify/provide additional script for old SSSD? Remeber that trusts with AD are most likely established when IPA clients are already rolled out. Changing ipa-client-install is not helpful for this case since the clients are already there. Perhaps a better approach would be documentation for non-SSSD case and a simple snippet that can be run alone or in use with puppet/etc to deploy massively. The snippet would use SSSDConfig Python API to add needed modifications to the clients' SSSD configuration. We can even extend IPA server tools to allow generating such snippets based on the trusts configuration. After all, we do have control over IPA server in such cases. I have updated wiki page with discussed ideas. Sorry but this is not enough. I do not see a discussion the design about the client side solutuon procedure. I am looking for a session that would contain a table (or like): -- | Type/Version of the client | Action| -- | Solaris/HP-UX/AIX (non sssd) | Configure manually to recognize AD as | || a domain following following steps ...| -- | Clients that have SSSD | If the client is already installed| | before 1.9 | and configured do X | || If it is a fresh install of the | || client do Y | -- | SSSD 1.9 and later | Use the following ipa-client-install | || flags XYZ and/or authconfig command | || ABC | -- Can something like this be added to wiki and corresponding tickets to provide a testable replacements for XYZ above be filed in trac? I've added more, including three tickets to cover specific configurations. Unfortunately, we have limits in multiple search bases approach by the commercial UNIX vendors since their LDAP modules do not support multiple search bases. For all of those platforms there is PADL pam_ldap available which can be used for the same purpose. If we still want to support native pam_ldap on Solaris (which don't work with multiple search bases), we'd have to merge LDAP trees. Alexander, in my initial proposal I said that trusted users should be put in the same tree as compat users, it was exactly to address this problem. We do not need to cause more problems by using multiple search trees IMO. Ok, since I wanted to re-use slapi-nis anyway, this only means adding one more config attribute to slapi-nis configuration that will ask it to look into NSS in addition to the main query. In which order these queries should be performed? first to LDAP then NSS or first
Re: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts
Simo Sorce wrote: On Fri, 2013-05-31 at 16:35 +0300, Alexander Bokovoy wrote: On Fri, 31 May 2013, Simo Sorce wrote: On Fri, 2013-05-31 at 10:54 +0300, Alexander Bokovoy wrote: On Thu, 30 May 2013, Dmitri Pal wrote: [...] For Lunix and older SSSD version we in fact have a problem. What I want to avoid is to have to define procedures and patches for all ^^ ? the clients. However if you use ipa-client-install it would configure sssd the old way. How to make it configured the new way? Manually? This is error prone and people will be reluctant to reconfigure SSSD. Automatically? Means patches to all the versions of the clients. How we are going to deal with the huge test matrix? I think rolling out patches to old sssd versions is not a good idea and I think we won't have the time to prepare all the needed patches in a reasonable time-frame. For SSSD versions which do not allow multiple search bases (1.5 and 1.6) I would suggest to add a new domain section for the AD user with LDAP and Kerberos provider. This would allow IPA users to works as before and add the AD users to the client. Maybe this would also be a better solution for the other SSSD versions instead of multiple search bases, at least it's a solution for all versions. Since we have the python config API for SSSD the needed changes to the sssd.conf might be scriptable with a reasonable effort. Maybe this can be added to ipa-client-install with a new option like --enable-legacy-trust-support which can add the news section to existing configuration or include it for new installations? Bigger question is what is simpler: write configuration instructions or modify/provide additional script for old SSSD? Remeber that trusts with AD are most likely established when IPA clients are already rolled out. Changing ipa-client-install is not helpful for this case since the clients are already there. Perhaps a better approach would be documentation for non-SSSD case and a simple snippet that can be run alone or in use with puppet/etc to deploy massively. The snippet would use SSSDConfig Python API to add needed modifications to the clients' SSSD configuration. We can even extend IPA server tools to allow generating such snippets based on the trusts configuration. After all, we do have control over IPA server in such cases. I have updated wiki page with discussed ideas. Sorry but this is not enough. I do not see a discussion the design about the client side solutuon procedure. I am looking for a session that would contain a table (or like): -- | Type/Version of the client | Action| -- | Solaris/HP-UX/AIX (non sssd) | Configure manually to recognize AD as | || a domain following following steps ...| -- | Clients that have SSSD | If the client is already installed| | before 1.9 | and configured do X | || If it is a fresh install of the | || client do Y | -- | SSSD 1.9 and later | Use the following ipa-client-install | || flags XYZ and/or authconfig command | || ABC | -- Can something like this be added to wiki and corresponding tickets to provide a testable replacements for XYZ above be filed in trac? I've added more, including three tickets to cover specific configurations. Unfortunately, we have limits in multiple search bases approach by the commercial UNIX vendors since their LDAP modules do not support multiple search bases. For all of those platforms there is PADL pam_ldap available which can be used for the same purpose. If we still want to support native pam_ldap on Solaris (which don't work with multiple search bases), we'd have to merge LDAP trees. Alexander, in my initial proposal I said that trusted users should be put in the same tree as compat users, it was exactly to address this problem. We do not need to cause more problems by using multiple search trees IMO. Ok, since I wanted to re-use slapi-nis anyway, this only means adding one more config attribute to slapi-nis configuration that will ask it to look into NSS in addition to the main query. In which order these queries should be performed? first to LDAP then NSS or first to NSS then to LDAP? I guess the answer depends on specific setup -- if all your users in AD, you'd like to look at them first. If we cache stuff in memory I am not sure it matters much. Note that
Re: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts
On Fri, 2013-05-31 at 10:35 -0400, Rob Crittenden wrote: Simo Sorce wrote: On Fri, 2013-05-31 at 16:35 +0300, Alexander Bokovoy wrote: On Fri, 31 May 2013, Simo Sorce wrote: On Fri, 2013-05-31 at 10:54 +0300, Alexander Bokovoy wrote: On Thu, 30 May 2013, Dmitri Pal wrote: [...] For Lunix and older SSSD version we in fact have a problem. What I want to avoid is to have to define procedures and patches for all ^^ ? the clients. However if you use ipa-client-install it would configure sssd the old way. How to make it configured the new way? Manually? This is error prone and people will be reluctant to reconfigure SSSD. Automatically? Means patches to all the versions of the clients. How we are going to deal with the huge test matrix? I think rolling out patches to old sssd versions is not a good idea and I think we won't have the time to prepare all the needed patches in a reasonable time-frame. For SSSD versions which do not allow multiple search bases (1.5 and 1.6) I would suggest to add a new domain section for the AD user with LDAP and Kerberos provider. This would allow IPA users to works as before and add the AD users to the client. Maybe this would also be a better solution for the other SSSD versions instead of multiple search bases, at least it's a solution for all versions. Since we have the python config API for SSSD the needed changes to the sssd.conf might be scriptable with a reasonable effort. Maybe this can be added to ipa-client-install with a new option like --enable-legacy-trust-support which can add the news section to existing configuration or include it for new installations? Bigger question is what is simpler: write configuration instructions or modify/provide additional script for old SSSD? Remeber that trusts with AD are most likely established when IPA clients are already rolled out. Changing ipa-client-install is not helpful for this case since the clients are already there. Perhaps a better approach would be documentation for non-SSSD case and a simple snippet that can be run alone or in use with puppet/etc to deploy massively. The snippet would use SSSDConfig Python API to add needed modifications to the clients' SSSD configuration. We can even extend IPA server tools to allow generating such snippets based on the trusts configuration. After all, we do have control over IPA server in such cases. I have updated wiki page with discussed ideas. Sorry but this is not enough. I do not see a discussion the design about the client side solutuon procedure. I am looking for a session that would contain a table (or like): -- | Type/Version of the client | Action | -- | Solaris/HP-UX/AIX (non sssd) | Configure manually to recognize AD as | || a domain following following steps ...| -- | Clients that have SSSD | If the client is already installed | | before 1.9 | and configured do X | || If it is a fresh install of the | || client do Y | -- | SSSD 1.9 and later | Use the following ipa-client-install | || flags XYZ and/or authconfig command | || ABC | -- Can something like this be added to wiki and corresponding tickets to provide a testable replacements for XYZ above be filed in trac? I've added more, including three tickets to cover specific configurations. Unfortunately, we have limits in multiple search bases approach by the commercial UNIX vendors since their LDAP modules do not support multiple search bases. For all of those platforms there is PADL pam_ldap available which can be used for the same purpose. If we still want to support native pam_ldap on Solaris (which don't work with multiple search bases), we'd have to merge LDAP trees. Alexander, in my initial proposal I said that trusted users should be put in the same tree as compat users, it was exactly to address this problem. We do not need to cause more problems by using multiple search trees IMO. Ok, since I wanted to re-use slapi-nis anyway, this only means adding one more config attribute to slapi-nis configuration that will ask it to look into NSS in addition to the main query. In
Re: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts
On Wed, May 29, 2013 at 09:53:14AM -0400, Dmitri Pal wrote: On 05/29/2013 03:28 AM, Sumit Bose wrote: On Wed, May 29, 2013 at 08:38:37AM +0300, Alexander Bokovoy wrote: On Tue, 28 May 2013, Dmitri Pal wrote: On 05/28/2013 04:29 PM, Alexander Bokovoy wrote: On Tue, 28 May 2013, Dmitri Pal wrote: On 05/28/2013 03:48 PM, Alexander Bokovoy wrote: On Tue, 28 May 2013, Dmitri Pal wrote: On 05/28/2013 07:50 AM, Alexander Bokovoy wrote: Hi, http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts = Overview = Since version 3.0 FreeIPA supports cross-realm trusts with Active Directory. In order to allow AD users to utilize services on IPA clients, up to date version of SSSD should be configured at the IPA client. In case it is not possible to install and configure SSSD 1.09, Active Directory users cannot access services on IPA clients. This feature is designed to bridge the gap and provide minimal compatibility level that allows to log-in to IPA clients for AD users. IPA clients will be able to use any reasonable nss_ldap/pam_ldap/sssd version. = Use Cases = Access to IPA client machine resources for AD users in case IPA client cannot utilize up to date version of SSSD with native support for IPA cross-realm trusts. = Design= Since IPA client is configured with the use of older SSSD or nss_ldap/pam_ldap, all work should be performed at the IPA master. Primary design decision is to provide a separate LDAP tree, similar to compat tree, that has following features: * information about both IPA and AD users can be queried; * it ispossible to enumerate members of IPA and AD groups; * authentication bind to IPA LDAP as AD users should automatically * trigger obtaining ticket from AD DC; in case TGT is obtained, * authentication bind should be treated as successful. From a client perspective, use of the separate LDAP tree is viewed as traditional nss_ldap/pam_ldap configuration. Proposed base for the LDAP tree: '''cn=users,cn=trust-accounts,dc=example,dc=com''' = Implementation = # IPA server sets SSSD configuration to 'ipa_server_mode = true' on install or upgrade # ipa-adtrust-install configures additional directory server plugin to serve trusted domains tree # Directory server plugin uses getpwnam_r(), getgrnam_r() and related calls to obtain information about AD user. For IPA users the information is fetched directly from the LDAP. # IPA KDC database driver adds MS-PAC information into ticket granting ticket for host/fqdn@REALM principal of IPA master. This is required to allow SSSD on IPA master to authenticate against AD using host/fqdn@REALM principal. For SSSD design see https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode = Feature Management = === UI === The feature is transparent and not exposed in UI === CLI === The feature is not directly exposed in CLI. IPA idrange management is expanded to specify idrange type (IPA local, AD trust, AD with winsync, IPA trust, ..) to affect the way how AD users SIDs are mapped to POSIX IDs. = Major configuration options and enablement = sssd.conf will have 'ipa_server_mode = true' set for IPA master. = Replication = No effect on replication. Since directory server plugin is only configured when ipa-adtrust-install is run, IPA masters may opt out from serving AD clients. = Updates and Upgrades = During upgrade of IPA master, sssd.conf should be updated to set 'ipa_server_mode = true'. = Dependencies = Depends on SSSD implementing IPA server mode (sssd 1.10.x) = External Impact = https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode = Backup and Restore = No external configuration files are affected = Test Plan = Testing the feature will require following: # Configure IPA to serve AD trusts # Establish trust with AD domain # Configure a client to use nss_ldap/pam_ldap against AD-compatible tree # Attempt to log-in to the client as AD user = RFE Author = [[User:Ab|ab]] ([[User talk:Ab|talk]]) Can you please explain how the older SSSD or other UNIX versions would use Kerberos for authentication? pam_krb5 should work as it is, as well as older SSSD, since any AD user attempting to connect using GSSAPI to IPA services will have cross-realm TGT issued for us by the trusting AD DC prior to that attempt. The whole idea was to make sure for old clients these users will look like normal users, via nss_ldap/SSSD. We still will need to configure principal mapping in /etc/krb5.conf like we do for AD users with trusts. I thought we would have to issue some patch for client to switch the clients from using Kerberos for authentication to using LDAP. No need to. pam_ldap would go through LDAP bind automatically, that's why the proposal talks about attempting to obtain TGT in
Re: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts
On Thu, 30 May 2013, Sumit Bose wrote: On Wed, May 29, 2013 at 09:53:14AM -0400, Dmitri Pal wrote: On 05/29/2013 03:28 AM, Sumit Bose wrote: On Wed, May 29, 2013 at 08:38:37AM +0300, Alexander Bokovoy wrote: On Tue, 28 May 2013, Dmitri Pal wrote: On 05/28/2013 04:29 PM, Alexander Bokovoy wrote: On Tue, 28 May 2013, Dmitri Pal wrote: On 05/28/2013 03:48 PM, Alexander Bokovoy wrote: On Tue, 28 May 2013, Dmitri Pal wrote: On 05/28/2013 07:50 AM, Alexander Bokovoy wrote: Hi, http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts = Overview = Since version 3.0 FreeIPA supports cross-realm trusts with Active Directory. In order to allow AD users to utilize services on IPA clients, up to date version of SSSD should be configured at the IPA client. In case it is not possible to install and configure SSSD 1.09, Active Directory users cannot access services on IPA clients. This feature is designed to bridge the gap and provide minimal compatibility level that allows to log-in to IPA clients for AD users. IPA clients will be able to use any reasonable nss_ldap/pam_ldap/sssd version. = Use Cases = Access to IPA client machine resources for AD users in case IPA client cannot utilize up to date version of SSSD with native support for IPA cross-realm trusts. = Design= Since IPA client is configured with the use of older SSSD or nss_ldap/pam_ldap, all work should be performed at the IPA master. Primary design decision is to provide a separate LDAP tree, similar to compat tree, that has following features: * information about both IPA and AD users can be queried; * it ispossible to enumerate members of IPA and AD groups; * authentication bind to IPA LDAP as AD users should automatically * trigger obtaining ticket from AD DC; in case TGT is obtained, * authentication bind should be treated as successful. From a client perspective, use of the separate LDAP tree is viewed as traditional nss_ldap/pam_ldap configuration. Proposed base for the LDAP tree: '''cn=users,cn=trust-accounts,dc=example,dc=com''' = Implementation = # IPA server sets SSSD configuration to 'ipa_server_mode = true' on install or upgrade # ipa-adtrust-install configures additional directory server plugin to serve trusted domains tree # Directory server plugin uses getpwnam_r(), getgrnam_r() and related calls to obtain information about AD user. For IPA users the information is fetched directly from the LDAP. # IPA KDC database driver adds MS-PAC information into ticket granting ticket for host/fqdn@REALM principal of IPA master. This is required to allow SSSD on IPA master to authenticate against AD using host/fqdn@REALM principal. For SSSD design see https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode = Feature Management = === UI === The feature is transparent and not exposed in UI === CLI === The feature is not directly exposed in CLI. IPA idrange management is expanded to specify idrange type (IPA local, AD trust, AD with winsync, IPA trust, ..) to affect the way how AD users SIDs are mapped to POSIX IDs. = Major configuration options and enablement = sssd.conf will have 'ipa_server_mode = true' set for IPA master. = Replication = No effect on replication. Since directory server plugin is only configured when ipa-adtrust-install is run, IPA masters may opt out from serving AD clients. = Updates and Upgrades = During upgrade of IPA master, sssd.conf should be updated to set 'ipa_server_mode = true'. = Dependencies = Depends on SSSD implementing IPA server mode (sssd 1.10.x) = External Impact = https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode = Backup and Restore = No external configuration files are affected = Test Plan = Testing the feature will require following: # Configure IPA to serve AD trusts # Establish trust with AD domain # Configure a client to use nss_ldap/pam_ldap against AD-compatible tree # Attempt to log-in to the client as AD user = RFE Author = [[User:Ab|ab]] ([[User talk:Ab|talk]]) Can you please explain how the older SSSD or other UNIX versions would use Kerberos for authentication? pam_krb5 should work as it is, as well as older SSSD, since any AD user attempting to connect using GSSAPI to IPA services will have cross-realm TGT issued for us by the trusting AD DC prior to that attempt. The whole idea was to make sure for old clients these users will look like normal users, via nss_ldap/SSSD. We still will need to configure principal mapping in /etc/krb5.conf like we do for AD users with trusts. I thought we would have to issue some patch for client to switch the clients from using Kerberos for authentication to using LDAP. No need to. pam_ldap would go through LDAP bind automatically, that's why the proposal talks about attempting to obtain TGT in place of a user instead of proxying such LDAP bind back to AD DC. This would require us enforcing clear
Re: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts
[...] For Lunix and older SSSD version we in fact have a problem. What I want to avoid is to have to define procedures and patches for all ^^ ? the clients. However if you use ipa-client-install it would configure sssd the old way. How to make it configured the new way? Manually? This is error prone and people will be reluctant to reconfigure SSSD. Automatically? Means patches to all the versions of the clients. How we are going to deal with the huge test matrix? I think rolling out patches to old sssd versions is not a good idea and I think we won't have the time to prepare all the needed patches in a reasonable time-frame. For SSSD versions which do not allow multiple search bases (1.5 and 1.6) I would suggest to add a new domain section for the AD user with LDAP and Kerberos provider. This would allow IPA users to works as before and add the AD users to the client. Maybe this would also be a better solution for the other SSSD versions instead of multiple search bases, at least it's a solution for all versions. Since we have the python config API for SSSD the needed changes to the sssd.conf might be scriptable with a reasonable effort. Maybe this can be added to ipa-client-install with a new option like --enable-legacy-trust-support which can add the news section to existing configuration or include it for new installations? Bigger question is what is simpler: write configuration instructions or modify/provide additional script for old SSSD? Remeber that trusts with AD are most likely established when IPA clients are already rolled out. Changing ipa-client-install is not helpful for this case since the clients are already there. Perhaps a better approach would be documentation for non-SSSD case and a simple snippet that can be run alone or in use with puppet/etc to deploy massively. The snippet would use SSSDConfig Python API to add needed modifications to the clients' SSSD configuration. We can even extend IPA server tools to allow generating such snippets based on the trusts configuration. After all, we do have control over IPA server in such cases. I have updated wiki page with discussed ideas. Sorry but this is not enough. I do not see a discussion the design about the client side solutuon procedure. I am looking for a session that would contain a table (or like): -- | Type/Version of the client | Action| -- | Solaris/HP-UX/AIX (non sssd) | Configure manually to recognize AD as | || a domain following following steps ...| -- | Clients that have SSSD | If the client is already installed| | before 1.9 | and configured do X | || If it is a fresh install of the | || client do Y | -- | SSSD 1.9 and later | Use the following ipa-client-install | || flags XYZ and/or authconfig command | || ABC | -- Can something like this be added to wiki and corresponding tickets to provide a testable replacements for XYZ above be filed in trac? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts
On Wed, May 29, 2013 at 08:38:37AM +0300, Alexander Bokovoy wrote: On Tue, 28 May 2013, Dmitri Pal wrote: On 05/28/2013 04:29 PM, Alexander Bokovoy wrote: On Tue, 28 May 2013, Dmitri Pal wrote: On 05/28/2013 03:48 PM, Alexander Bokovoy wrote: On Tue, 28 May 2013, Dmitri Pal wrote: On 05/28/2013 07:50 AM, Alexander Bokovoy wrote: Hi, http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts = Overview = Since version 3.0 FreeIPA supports cross-realm trusts with Active Directory. In order to allow AD users to utilize services on IPA clients, up to date version of SSSD should be configured at the IPA client. In case it is not possible to install and configure SSSD 1.09, Active Directory users cannot access services on IPA clients. This feature is designed to bridge the gap and provide minimal compatibility level that allows to log-in to IPA clients for AD users. IPA clients will be able to use any reasonable nss_ldap/pam_ldap/sssd version. = Use Cases = Access to IPA client machine resources for AD users in case IPA client cannot utilize up to date version of SSSD with native support for IPA cross-realm trusts. = Design= Since IPA client is configured with the use of older SSSD or nss_ldap/pam_ldap, all work should be performed at the IPA master. Primary design decision is to provide a separate LDAP tree, similar to compat tree, that has following features: * information about both IPA and AD users can be queried; * it ispossible to enumerate members of IPA and AD groups; * authentication bind to IPA LDAP as AD users should automatically * trigger obtaining ticket from AD DC; in case TGT is obtained, * authentication bind should be treated as successful. From a client perspective, use of the separate LDAP tree is viewed as traditional nss_ldap/pam_ldap configuration. Proposed base for the LDAP tree: '''cn=users,cn=trust-accounts,dc=example,dc=com''' = Implementation = # IPA server sets SSSD configuration to 'ipa_server_mode = true' on install or upgrade # ipa-adtrust-install configures additional directory server plugin to serve trusted domains tree # Directory server plugin uses getpwnam_r(), getgrnam_r() and related calls to obtain information about AD user. For IPA users the information is fetched directly from the LDAP. # IPA KDC database driver adds MS-PAC information into ticket granting ticket for host/fqdn@REALM principal of IPA master. This is required to allow SSSD on IPA master to authenticate against AD using host/fqdn@REALM principal. For SSSD design see https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode = Feature Management = === UI === The feature is transparent and not exposed in UI === CLI === The feature is not directly exposed in CLI. IPA idrange management is expanded to specify idrange type (IPA local, AD trust, AD with winsync, IPA trust, ..) to affect the way how AD users SIDs are mapped to POSIX IDs. = Major configuration options and enablement = sssd.conf will have 'ipa_server_mode = true' set for IPA master. = Replication = No effect on replication. Since directory server plugin is only configured when ipa-adtrust-install is run, IPA masters may opt out from serving AD clients. = Updates and Upgrades = During upgrade of IPA master, sssd.conf should be updated to set 'ipa_server_mode = true'. = Dependencies = Depends on SSSD implementing IPA server mode (sssd 1.10.x) = External Impact = https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode = Backup and Restore = No external configuration files are affected = Test Plan = Testing the feature will require following: # Configure IPA to serve AD trusts # Establish trust with AD domain # Configure a client to use nss_ldap/pam_ldap against AD-compatible tree # Attempt to log-in to the client as AD user = RFE Author = [[User:Ab|ab]] ([[User talk:Ab|talk]]) Can you please explain how the older SSSD or other UNIX versions would use Kerberos for authentication? pam_krb5 should work as it is, as well as older SSSD, since any AD user attempting to connect using GSSAPI to IPA services will have cross-realm TGT issued for us by the trusting AD DC prior to that attempt. The whole idea was to make sure for old clients these users will look like normal users, via nss_ldap/SSSD. We still will need to configure principal mapping in /etc/krb5.conf like we do for AD users with trusts. I thought we would have to issue some patch for client to switch the clients from using Kerberos for authentication to using LDAP. No need to. pam_ldap would go through LDAP bind automatically, that's why the proposal talks about attempting to obtain TGT in place of a user instead of proxying such LDAP bind back to AD DC. This would require us enforcing clear password bind over TLS/SSL but it is simpler to achieve. I am missing something. How a simple kinit
Re: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts
On Tue, May 28, 2013 at 02:50:59PM +0300, Alexander Bokovoy wrote: Hi, http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts = Overview = Since version 3.0 FreeIPA supports cross-realm trusts with Active Directory. In order to allow AD users to utilize services on IPA clients, up to date version of SSSD should be configured at the IPA client. In case it is not possible to install and configure SSSD 1.09, Active Directory users cannot access services on IPA clients. This feature is designed to bridge the gap and provide minimal compatibility level that allows to log-in to IPA clients for AD users. IPA clients will be able to use any reasonable nss_ldap/pam_ldap/sssd version. = Use Cases = Access to IPA client machine resources for AD users in case IPA client cannot utilize up to date version of SSSD with native support for IPA cross-realm trusts. = Design= Since IPA client is configured with the use of older SSSD or nss_ldap/pam_ldap, all work should be performed at the IPA master. Primary design decision is to provide a separate LDAP tree, similar to compat tree, that has following features: * information about both IPA and AD users can be queried; * it ispossible to enumerate members of IPA and AD groups; * authentication bind to IPA LDAP as AD users should automatically * trigger obtaining ticket from AD DC; in case TGT is obtained, * authentication bind should be treated as successful. From a client perspective, use of the separate LDAP tree is viewed as traditional nss_ldap/pam_ldap configuration. Proposed base for the LDAP tree: '''cn=users,cn=trust-accounts,dc=example,dc=com''' I guess older SSSD versions, e.g. 1.8. might be the most difficult use cases because they already support some specific features for IPA users and groups, e.g. HBAC, netgroups, SELinux and automount maps. Since most of them depends on DNs one way or the other I think older SSSD version must continue to use the main tree for IPA users and groups and local look at the new tree for trusted accounts. Luckily multiple search bases were introduced in SSSD 1.7, I wonder if older version have to be supported as well? But if multiple search bases are used the IPA users and groups should not be visible in the new tree for trusted accounts. Maybe the new plugin can offer different trees like - cn=users,cn=trust-accounts,dc=example,dc=com - cn=users,cn=trust-accounts-sssd,dc=example,dc=com where the first contains IPA and AD accounts as mentioned above and the latter only the AD accounts? Since we are planning to do the lookups on the fly I think both trees can be handled in the same code path and the path name is just config option which switches the IPA accounts on and off respectively. With iyet another tree it might be also possible to support either rfc2307 or rfc2037bis. I assume that the plan is that the new tree will use rfc2307bis but I wonder if we have to support clients which only support rcf2307. bye, Sumit = Implementation = # IPA server sets SSSD configuration to 'ipa_server_mode = true' on install or upgrade # ipa-adtrust-install configures additional directory server plugin to serve trusted domains tree # Directory server plugin uses getpwnam_r(), getgrnam_r() and related calls to obtain information about AD user. For IPA users the information is fetched directly from the LDAP. # IPA KDC database driver adds MS-PAC information into ticket granting ticket for host/fqdn@REALM principal of IPA master. This is required to allow SSSD on IPA master to authenticate against AD using host/fqdn@REALM principal. For SSSD design see https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode = Feature Management = === UI === The feature is transparent and not exposed in UI === CLI === The feature is not directly exposed in CLI. IPA idrange management is expanded to specify idrange type (IPA local, AD trust, AD with winsync, IPA trust, ..) to affect the way how AD users SIDs are mapped to POSIX IDs. = Major configuration options and enablement = sssd.conf will have 'ipa_server_mode = true' set for IPA master. = Replication = No effect on replication. Since directory server plugin is only configured when ipa-adtrust-install is run, IPA masters may opt out from serving AD clients. = Updates and Upgrades = During upgrade of IPA master, sssd.conf should be updated to set 'ipa_server_mode = true'. = Dependencies = Depends on SSSD implementing IPA server mode (sssd 1.10.x) = External Impact = https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode = Backup and Restore = No external configuration files are affected = Test Plan = Testing the feature will require following: # Configure IPA to serve AD trusts # Establish trust with AD domain # Configure a client to use nss_ldap/pam_ldap against AD-compatible tree # Attempt to log-in to the client as AD user = RFE Author
Re: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts
On Wed, 29 May 2013, Sumit Bose wrote: On Tue, May 28, 2013 at 02:50:59PM +0300, Alexander Bokovoy wrote: Hi, http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts = Overview = Since version 3.0 FreeIPA supports cross-realm trusts with Active Directory. In order to allow AD users to utilize services on IPA clients, up to date version of SSSD should be configured at the IPA client. In case it is not possible to install and configure SSSD 1.09, Active Directory users cannot access services on IPA clients. This feature is designed to bridge the gap and provide minimal compatibility level that allows to log-in to IPA clients for AD users. IPA clients will be able to use any reasonable nss_ldap/pam_ldap/sssd version. = Use Cases = Access to IPA client machine resources for AD users in case IPA client cannot utilize up to date version of SSSD with native support for IPA cross-realm trusts. = Design= Since IPA client is configured with the use of older SSSD or nss_ldap/pam_ldap, all work should be performed at the IPA master. Primary design decision is to provide a separate LDAP tree, similar to compat tree, that has following features: * information about both IPA and AD users can be queried; * it ispossible to enumerate members of IPA and AD groups; * authentication bind to IPA LDAP as AD users should automatically * trigger obtaining ticket from AD DC; in case TGT is obtained, * authentication bind should be treated as successful. From a client perspective, use of the separate LDAP tree is viewed as traditional nss_ldap/pam_ldap configuration. Proposed base for the LDAP tree: '''cn=users,cn=trust-accounts,dc=example,dc=com''' I guess older SSSD versions, e.g. 1.8. might be the most difficult use cases because they already support some specific features for IPA users and groups, e.g. HBAC, netgroups, SELinux and automount maps. Since most of them depends on DNs one way or the other I think older SSSD version must continue to use the main tree for IPA users and groups and local look at the new tree for trusted accounts. Luckily multiple search bases were introduced in SSSD 1.7, I wonder if older version have to be supported as well? But if multiple search bases are used the IPA users and groups should not be visible in the new tree for trusted accounts. Maybe the new plugin can offer different trees like - cn=users,cn=trust-accounts,dc=example,dc=com - cn=users,cn=trust-accounts-sssd,dc=example,dc=com where the first contains IPA and AD accounts as mentioned above and the latter only the AD accounts? Since we are planning to do the lookups on the fly I think both trees can be handled in the same code path and the path name is just config option which switches the IPA accounts on and off respectively. With iyet another tree it might be also possible to support either rfc2307 or rfc2037bis. I assume that the plan is that the new tree will use rfc2307bis but I wonder if we have to support clients which only support rcf2307. Yep. Summarizing for the list discussion we had with Sumit on IRC, I think we can re-use slapi-nis plugin for the purpose of this feature. The way slapi-nis works for schema compatibility is that one needs to define first a subtree to search against, with a filter, and then additional transformations are applied to the result of search. The end result is presented to the client. What we need to do is to make possible to return a result of initial 'search' against SSSD instead of actual LDAP subtree. A 'search' result is then processed according to defined transformation rules. slapi-nis supports multiple resulting trees already, this solves the problem Sumit raises above. Additionally, for LDAP auth bind we need to make sure it is actually possible to hook to in a directory server plugin for a virtual DN like slapi-nis presents. This is something Sumit and I need to check with 389-ds developers. We already have some support for that with new feature to allow fallbacks for SASL auth but in this case we need to use simple bind to get hold of the password (to kinit agasint AD DC) over secure channel. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts
On 05/29/2013 03:28 AM, Sumit Bose wrote: On Wed, May 29, 2013 at 08:38:37AM +0300, Alexander Bokovoy wrote: On Tue, 28 May 2013, Dmitri Pal wrote: On 05/28/2013 04:29 PM, Alexander Bokovoy wrote: On Tue, 28 May 2013, Dmitri Pal wrote: On 05/28/2013 03:48 PM, Alexander Bokovoy wrote: On Tue, 28 May 2013, Dmitri Pal wrote: On 05/28/2013 07:50 AM, Alexander Bokovoy wrote: Hi, http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts = Overview = Since version 3.0 FreeIPA supports cross-realm trusts with Active Directory. In order to allow AD users to utilize services on IPA clients, up to date version of SSSD should be configured at the IPA client. In case it is not possible to install and configure SSSD 1.09, Active Directory users cannot access services on IPA clients. This feature is designed to bridge the gap and provide minimal compatibility level that allows to log-in to IPA clients for AD users. IPA clients will be able to use any reasonable nss_ldap/pam_ldap/sssd version. = Use Cases = Access to IPA client machine resources for AD users in case IPA client cannot utilize up to date version of SSSD with native support for IPA cross-realm trusts. = Design= Since IPA client is configured with the use of older SSSD or nss_ldap/pam_ldap, all work should be performed at the IPA master. Primary design decision is to provide a separate LDAP tree, similar to compat tree, that has following features: * information about both IPA and AD users can be queried; * it ispossible to enumerate members of IPA and AD groups; * authentication bind to IPA LDAP as AD users should automatically * trigger obtaining ticket from AD DC; in case TGT is obtained, * authentication bind should be treated as successful. From a client perspective, use of the separate LDAP tree is viewed as traditional nss_ldap/pam_ldap configuration. Proposed base for the LDAP tree: '''cn=users,cn=trust-accounts,dc=example,dc=com''' = Implementation = # IPA server sets SSSD configuration to 'ipa_server_mode = true' on install or upgrade # ipa-adtrust-install configures additional directory server plugin to serve trusted domains tree # Directory server plugin uses getpwnam_r(), getgrnam_r() and related calls to obtain information about AD user. For IPA users the information is fetched directly from the LDAP. # IPA KDC database driver adds MS-PAC information into ticket granting ticket for host/fqdn@REALM principal of IPA master. This is required to allow SSSD on IPA master to authenticate against AD using host/fqdn@REALM principal. For SSSD design see https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode = Feature Management = === UI === The feature is transparent and not exposed in UI === CLI === The feature is not directly exposed in CLI. IPA idrange management is expanded to specify idrange type (IPA local, AD trust, AD with winsync, IPA trust, ..) to affect the way how AD users SIDs are mapped to POSIX IDs. = Major configuration options and enablement = sssd.conf will have 'ipa_server_mode = true' set for IPA master. = Replication = No effect on replication. Since directory server plugin is only configured when ipa-adtrust-install is run, IPA masters may opt out from serving AD clients. = Updates and Upgrades = During upgrade of IPA master, sssd.conf should be updated to set 'ipa_server_mode = true'. = Dependencies = Depends on SSSD implementing IPA server mode (sssd 1.10.x) = External Impact = https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode = Backup and Restore = No external configuration files are affected = Test Plan = Testing the feature will require following: # Configure IPA to serve AD trusts # Establish trust with AD domain # Configure a client to use nss_ldap/pam_ldap against AD-compatible tree # Attempt to log-in to the client as AD user = RFE Author = [[User:Ab|ab]] ([[User talk:Ab|talk]]) Can you please explain how the older SSSD or other UNIX versions would use Kerberos for authentication? pam_krb5 should work as it is, as well as older SSSD, since any AD user attempting to connect using GSSAPI to IPA services will have cross-realm TGT issued for us by the trusting AD DC prior to that attempt. The whole idea was to make sure for old clients these users will look like normal users, via nss_ldap/SSSD. We still will need to configure principal mapping in /etc/krb5.conf like we do for AD users with trusts. I thought we would have to issue some patch for client to switch the clients from using Kerberos for authentication to using LDAP. No need to. pam_ldap would go through LDAP bind automatically, that's why the proposal talks about attempting to obtain TGT in place of a user instead of proxying such LDAP bind back to AD DC. This would require us enforcing clear password bind over TLS/SSL but it is simpler to achieve. I am missing something. How a simple kinit
Re: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts
On Tue, May 28, 2013 at 02:50:59PM +0300, Alexander Bokovoy wrote: = Dependencies = Depends on SSSD implementing IPA server mode (sssd 1.10.x) Nitpick -- currently this is planned for 1.11 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts
On 05/28/2013 07:50 AM, Alexander Bokovoy wrote: Hi, http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts = Overview = Since version 3.0 FreeIPA supports cross-realm trusts with Active Directory. In order to allow AD users to utilize services on IPA clients, up to date version of SSSD should be configured at the IPA client. In case it is not possible to install and configure SSSD 1.09, Active Directory users cannot access services on IPA clients. This feature is designed to bridge the gap and provide minimal compatibility level that allows to log-in to IPA clients for AD users. IPA clients will be able to use any reasonable nss_ldap/pam_ldap/sssd version. = Use Cases = Access to IPA client machine resources for AD users in case IPA client cannot utilize up to date version of SSSD with native support for IPA cross-realm trusts. = Design= Since IPA client is configured with the use of older SSSD or nss_ldap/pam_ldap, all work should be performed at the IPA master. Primary design decision is to provide a separate LDAP tree, similar to compat tree, that has following features: * information about both IPA and AD users can be queried; * it ispossible to enumerate members of IPA and AD groups; * authentication bind to IPA LDAP as AD users should automatically * trigger obtaining ticket from AD DC; in case TGT is obtained, * authentication bind should be treated as successful. From a client perspective, use of the separate LDAP tree is viewed as traditional nss_ldap/pam_ldap configuration. Proposed base for the LDAP tree: '''cn=users,cn=trust-accounts,dc=example,dc=com''' = Implementation = # IPA server sets SSSD configuration to 'ipa_server_mode = true' on install or upgrade # ipa-adtrust-install configures additional directory server plugin to serve trusted domains tree # Directory server plugin uses getpwnam_r(), getgrnam_r() and related calls to obtain information about AD user. For IPA users the information is fetched directly from the LDAP. # IPA KDC database driver adds MS-PAC information into ticket granting ticket for host/fqdn@REALM principal of IPA master. This is required to allow SSSD on IPA master to authenticate against AD using host/fqdn@REALM principal. For SSSD design see https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode = Feature Management = === UI === The feature is transparent and not exposed in UI === CLI === The feature is not directly exposed in CLI. IPA idrange management is expanded to specify idrange type (IPA local, AD trust, AD with winsync, IPA trust, ..) to affect the way how AD users SIDs are mapped to POSIX IDs. = Major configuration options and enablement = sssd.conf will have 'ipa_server_mode = true' set for IPA master. = Replication = No effect on replication. Since directory server plugin is only configured when ipa-adtrust-install is run, IPA masters may opt out from serving AD clients. = Updates and Upgrades = During upgrade of IPA master, sssd.conf should be updated to set 'ipa_server_mode = true'. = Dependencies = Depends on SSSD implementing IPA server mode (sssd 1.10.x) = External Impact = https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode = Backup and Restore = No external configuration files are affected = Test Plan = Testing the feature will require following: # Configure IPA to serve AD trusts # Establish trust with AD domain # Configure a client to use nss_ldap/pam_ldap against AD-compatible tree # Attempt to log-in to the client as AD user = RFE Author = [[User:Ab|ab]] ([[User talk:Ab|talk]]) Can you please explain how the older SSSD or other UNIX versions would use Kerberos for authentication? I thought we would have to issue some patch for client to switch the clients from using Kerberos for authentication to using LDAP. Alternatively we should modify KDC to use the new extop and go though the SSSD on the IPA side but I do not see it mentioned anywhere. Can we get a bit more clarity about the Kerberos authentication workflow? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts
On Tue, 28 May 2013, Dmitri Pal wrote: On 05/28/2013 07:50 AM, Alexander Bokovoy wrote: Hi, http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts = Overview = Since version 3.0 FreeIPA supports cross-realm trusts with Active Directory. In order to allow AD users to utilize services on IPA clients, up to date version of SSSD should be configured at the IPA client. In case it is not possible to install and configure SSSD 1.09, Active Directory users cannot access services on IPA clients. This feature is designed to bridge the gap and provide minimal compatibility level that allows to log-in to IPA clients for AD users. IPA clients will be able to use any reasonable nss_ldap/pam_ldap/sssd version. = Use Cases = Access to IPA client machine resources for AD users in case IPA client cannot utilize up to date version of SSSD with native support for IPA cross-realm trusts. = Design= Since IPA client is configured with the use of older SSSD or nss_ldap/pam_ldap, all work should be performed at the IPA master. Primary design decision is to provide a separate LDAP tree, similar to compat tree, that has following features: * information about both IPA and AD users can be queried; * it ispossible to enumerate members of IPA and AD groups; * authentication bind to IPA LDAP as AD users should automatically * trigger obtaining ticket from AD DC; in case TGT is obtained, * authentication bind should be treated as successful. From a client perspective, use of the separate LDAP tree is viewed as traditional nss_ldap/pam_ldap configuration. Proposed base for the LDAP tree: '''cn=users,cn=trust-accounts,dc=example,dc=com''' = Implementation = # IPA server sets SSSD configuration to 'ipa_server_mode = true' on install or upgrade # ipa-adtrust-install configures additional directory server plugin to serve trusted domains tree # Directory server plugin uses getpwnam_r(), getgrnam_r() and related calls to obtain information about AD user. For IPA users the information is fetched directly from the LDAP. # IPA KDC database driver adds MS-PAC information into ticket granting ticket for host/fqdn@REALM principal of IPA master. This is required to allow SSSD on IPA master to authenticate against AD using host/fqdn@REALM principal. For SSSD design see https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode = Feature Management = === UI === The feature is transparent and not exposed in UI === CLI === The feature is not directly exposed in CLI. IPA idrange management is expanded to specify idrange type (IPA local, AD trust, AD with winsync, IPA trust, ..) to affect the way how AD users SIDs are mapped to POSIX IDs. = Major configuration options and enablement = sssd.conf will have 'ipa_server_mode = true' set for IPA master. = Replication = No effect on replication. Since directory server plugin is only configured when ipa-adtrust-install is run, IPA masters may opt out from serving AD clients. = Updates and Upgrades = During upgrade of IPA master, sssd.conf should be updated to set 'ipa_server_mode = true'. = Dependencies = Depends on SSSD implementing IPA server mode (sssd 1.10.x) = External Impact = https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode = Backup and Restore = No external configuration files are affected = Test Plan = Testing the feature will require following: # Configure IPA to serve AD trusts # Establish trust with AD domain # Configure a client to use nss_ldap/pam_ldap against AD-compatible tree # Attempt to log-in to the client as AD user = RFE Author = [[User:Ab|ab]] ([[User talk:Ab|talk]]) Can you please explain how the older SSSD or other UNIX versions would use Kerberos for authentication? pam_krb5 should work as it is, as well as older SSSD, since any AD user attempting to connect using GSSAPI to IPA services will have cross-realm TGT issued for us by the trusting AD DC prior to that attempt. The whole idea was to make sure for old clients these users will look like normal users, via nss_ldap/SSSD. We still will need to configure principal mapping in /etc/krb5.conf like we do for AD users with trusts. I thought we would have to issue some patch for client to switch the clients from using Kerberos for authentication to using LDAP. No need to. pam_ldap would go through LDAP bind automatically, that's why the proposal talks about attempting to obtain TGT in place of a user instead of proxying such LDAP bind back to AD DC. This would require us enforcing clear password bind over TLS/SSL but it is simpler to achieve. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts
On 05/28/2013 03:48 PM, Alexander Bokovoy wrote: On Tue, 28 May 2013, Dmitri Pal wrote: On 05/28/2013 07:50 AM, Alexander Bokovoy wrote: Hi, http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts = Overview = Since version 3.0 FreeIPA supports cross-realm trusts with Active Directory. In order to allow AD users to utilize services on IPA clients, up to date version of SSSD should be configured at the IPA client. In case it is not possible to install and configure SSSD 1.09, Active Directory users cannot access services on IPA clients. This feature is designed to bridge the gap and provide minimal compatibility level that allows to log-in to IPA clients for AD users. IPA clients will be able to use any reasonable nss_ldap/pam_ldap/sssd version. = Use Cases = Access to IPA client machine resources for AD users in case IPA client cannot utilize up to date version of SSSD with native support for IPA cross-realm trusts. = Design= Since IPA client is configured with the use of older SSSD or nss_ldap/pam_ldap, all work should be performed at the IPA master. Primary design decision is to provide a separate LDAP tree, similar to compat tree, that has following features: * information about both IPA and AD users can be queried; * it ispossible to enumerate members of IPA and AD groups; * authentication bind to IPA LDAP as AD users should automatically * trigger obtaining ticket from AD DC; in case TGT is obtained, * authentication bind should be treated as successful. From a client perspective, use of the separate LDAP tree is viewed as traditional nss_ldap/pam_ldap configuration. Proposed base for the LDAP tree: '''cn=users,cn=trust-accounts,dc=example,dc=com''' = Implementation = # IPA server sets SSSD configuration to 'ipa_server_mode = true' on install or upgrade # ipa-adtrust-install configures additional directory server plugin to serve trusted domains tree # Directory server plugin uses getpwnam_r(), getgrnam_r() and related calls to obtain information about AD user. For IPA users the information is fetched directly from the LDAP. # IPA KDC database driver adds MS-PAC information into ticket granting ticket for host/fqdn@REALM principal of IPA master. This is required to allow SSSD on IPA master to authenticate against AD using host/fqdn@REALM principal. For SSSD design see https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode = Feature Management = === UI === The feature is transparent and not exposed in UI === CLI === The feature is not directly exposed in CLI. IPA idrange management is expanded to specify idrange type (IPA local, AD trust, AD with winsync, IPA trust, ..) to affect the way how AD users SIDs are mapped to POSIX IDs. = Major configuration options and enablement = sssd.conf will have 'ipa_server_mode = true' set for IPA master. = Replication = No effect on replication. Since directory server plugin is only configured when ipa-adtrust-install is run, IPA masters may opt out from serving AD clients. = Updates and Upgrades = During upgrade of IPA master, sssd.conf should be updated to set 'ipa_server_mode = true'. = Dependencies = Depends on SSSD implementing IPA server mode (sssd 1.10.x) = External Impact = https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode = Backup and Restore = No external configuration files are affected = Test Plan = Testing the feature will require following: # Configure IPA to serve AD trusts # Establish trust with AD domain # Configure a client to use nss_ldap/pam_ldap against AD-compatible tree # Attempt to log-in to the client as AD user = RFE Author = [[User:Ab|ab]] ([[User talk:Ab|talk]]) Can you please explain how the older SSSD or other UNIX versions would use Kerberos for authentication? pam_krb5 should work as it is, as well as older SSSD, since any AD user attempting to connect using GSSAPI to IPA services will have cross-realm TGT issued for us by the trusting AD DC prior to that attempt. The whole idea was to make sure for old clients these users will look like normal users, via nss_ldap/SSSD. We still will need to configure principal mapping in /etc/krb5.conf like we do for AD users with trusts. I thought we would have to issue some patch for client to switch the clients from using Kerberos for authentication to using LDAP. No need to. pam_ldap would go through LDAP bind automatically, that's why the proposal talks about attempting to obtain TGT in place of a user instead of proxying such LDAP bind back to AD DC. This would require us enforcing clear password bind over TLS/SSL but it is simpler to achieve. I am missing something. How a simple kinit would work? Can you please describe the sequence and workflow? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/
Re: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts
On Tue, 28 May 2013, Dmitri Pal wrote: On 05/28/2013 03:48 PM, Alexander Bokovoy wrote: On Tue, 28 May 2013, Dmitri Pal wrote: On 05/28/2013 07:50 AM, Alexander Bokovoy wrote: Hi, http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts = Overview = Since version 3.0 FreeIPA supports cross-realm trusts with Active Directory. In order to allow AD users to utilize services on IPA clients, up to date version of SSSD should be configured at the IPA client. In case it is not possible to install and configure SSSD 1.09, Active Directory users cannot access services on IPA clients. This feature is designed to bridge the gap and provide minimal compatibility level that allows to log-in to IPA clients for AD users. IPA clients will be able to use any reasonable nss_ldap/pam_ldap/sssd version. = Use Cases = Access to IPA client machine resources for AD users in case IPA client cannot utilize up to date version of SSSD with native support for IPA cross-realm trusts. = Design= Since IPA client is configured with the use of older SSSD or nss_ldap/pam_ldap, all work should be performed at the IPA master. Primary design decision is to provide a separate LDAP tree, similar to compat tree, that has following features: * information about both IPA and AD users can be queried; * it ispossible to enumerate members of IPA and AD groups; * authentication bind to IPA LDAP as AD users should automatically * trigger obtaining ticket from AD DC; in case TGT is obtained, * authentication bind should be treated as successful. From a client perspective, use of the separate LDAP tree is viewed as traditional nss_ldap/pam_ldap configuration. Proposed base for the LDAP tree: '''cn=users,cn=trust-accounts,dc=example,dc=com''' = Implementation = # IPA server sets SSSD configuration to 'ipa_server_mode = true' on install or upgrade # ipa-adtrust-install configures additional directory server plugin to serve trusted domains tree # Directory server plugin uses getpwnam_r(), getgrnam_r() and related calls to obtain information about AD user. For IPA users the information is fetched directly from the LDAP. # IPA KDC database driver adds MS-PAC information into ticket granting ticket for host/fqdn@REALM principal of IPA master. This is required to allow SSSD on IPA master to authenticate against AD using host/fqdn@REALM principal. For SSSD design see https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode = Feature Management = === UI === The feature is transparent and not exposed in UI === CLI === The feature is not directly exposed in CLI. IPA idrange management is expanded to specify idrange type (IPA local, AD trust, AD with winsync, IPA trust, ..) to affect the way how AD users SIDs are mapped to POSIX IDs. = Major configuration options and enablement = sssd.conf will have 'ipa_server_mode = true' set for IPA master. = Replication = No effect on replication. Since directory server plugin is only configured when ipa-adtrust-install is run, IPA masters may opt out from serving AD clients. = Updates and Upgrades = During upgrade of IPA master, sssd.conf should be updated to set 'ipa_server_mode = true'. = Dependencies = Depends on SSSD implementing IPA server mode (sssd 1.10.x) = External Impact = https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode = Backup and Restore = No external configuration files are affected = Test Plan = Testing the feature will require following: # Configure IPA to serve AD trusts # Establish trust with AD domain # Configure a client to use nss_ldap/pam_ldap against AD-compatible tree # Attempt to log-in to the client as AD user = RFE Author = [[User:Ab|ab]] ([[User talk:Ab|talk]]) Can you please explain how the older SSSD or other UNIX versions would use Kerberos for authentication? pam_krb5 should work as it is, as well as older SSSD, since any AD user attempting to connect using GSSAPI to IPA services will have cross-realm TGT issued for us by the trusting AD DC prior to that attempt. The whole idea was to make sure for old clients these users will look like normal users, via nss_ldap/SSSD. We still will need to configure principal mapping in /etc/krb5.conf like we do for AD users with trusts. I thought we would have to issue some patch for client to switch the clients from using Kerberos for authentication to using LDAP. No need to. pam_ldap would go through LDAP bind automatically, that's why the proposal talks about attempting to obtain TGT in place of a user instead of proxying such LDAP bind back to AD DC. This would require us enforcing clear password bind over TLS/SSL but it is simpler to achieve. I am missing something. How a simple kinit would work? Can you please describe the sequence and workflow? I'm talking about the case when AD user logs in into IPA client using PuTTY from Windows machine. In such case there is already service ticket and cross-realm TGT available. For kinit on IPA client all what is needed is /etc/krb5.conf
Re: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts
On 05/28/2013 04:29 PM, Alexander Bokovoy wrote: On Tue, 28 May 2013, Dmitri Pal wrote: On 05/28/2013 03:48 PM, Alexander Bokovoy wrote: On Tue, 28 May 2013, Dmitri Pal wrote: On 05/28/2013 07:50 AM, Alexander Bokovoy wrote: Hi, http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts = Overview = Since version 3.0 FreeIPA supports cross-realm trusts with Active Directory. In order to allow AD users to utilize services on IPA clients, up to date version of SSSD should be configured at the IPA client. In case it is not possible to install and configure SSSD 1.09, Active Directory users cannot access services on IPA clients. This feature is designed to bridge the gap and provide minimal compatibility level that allows to log-in to IPA clients for AD users. IPA clients will be able to use any reasonable nss_ldap/pam_ldap/sssd version. = Use Cases = Access to IPA client machine resources for AD users in case IPA client cannot utilize up to date version of SSSD with native support for IPA cross-realm trusts. = Design= Since IPA client is configured with the use of older SSSD or nss_ldap/pam_ldap, all work should be performed at the IPA master. Primary design decision is to provide a separate LDAP tree, similar to compat tree, that has following features: * information about both IPA and AD users can be queried; * it ispossible to enumerate members of IPA and AD groups; * authentication bind to IPA LDAP as AD users should automatically * trigger obtaining ticket from AD DC; in case TGT is obtained, * authentication bind should be treated as successful. From a client perspective, use of the separate LDAP tree is viewed as traditional nss_ldap/pam_ldap configuration. Proposed base for the LDAP tree: '''cn=users,cn=trust-accounts,dc=example,dc=com''' = Implementation = # IPA server sets SSSD configuration to 'ipa_server_mode = true' on install or upgrade # ipa-adtrust-install configures additional directory server plugin to serve trusted domains tree # Directory server plugin uses getpwnam_r(), getgrnam_r() and related calls to obtain information about AD user. For IPA users the information is fetched directly from the LDAP. # IPA KDC database driver adds MS-PAC information into ticket granting ticket for host/fqdn@REALM principal of IPA master. This is required to allow SSSD on IPA master to authenticate against AD using host/fqdn@REALM principal. For SSSD design see https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode = Feature Management = === UI === The feature is transparent and not exposed in UI === CLI === The feature is not directly exposed in CLI. IPA idrange management is expanded to specify idrange type (IPA local, AD trust, AD with winsync, IPA trust, ..) to affect the way how AD users SIDs are mapped to POSIX IDs. = Major configuration options and enablement = sssd.conf will have 'ipa_server_mode = true' set for IPA master. = Replication = No effect on replication. Since directory server plugin is only configured when ipa-adtrust-install is run, IPA masters may opt out from serving AD clients. = Updates and Upgrades = During upgrade of IPA master, sssd.conf should be updated to set 'ipa_server_mode = true'. = Dependencies = Depends on SSSD implementing IPA server mode (sssd 1.10.x) = External Impact = https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode = Backup and Restore = No external configuration files are affected = Test Plan = Testing the feature will require following: # Configure IPA to serve AD trusts # Establish trust with AD domain # Configure a client to use nss_ldap/pam_ldap against AD-compatible tree # Attempt to log-in to the client as AD user = RFE Author = [[User:Ab|ab]] ([[User talk:Ab|talk]]) Can you please explain how the older SSSD or other UNIX versions would use Kerberos for authentication? pam_krb5 should work as it is, as well as older SSSD, since any AD user attempting to connect using GSSAPI to IPA services will have cross-realm TGT issued for us by the trusting AD DC prior to that attempt. The whole idea was to make sure for old clients these users will look like normal users, via nss_ldap/SSSD. We still will need to configure principal mapping in /etc/krb5.conf like we do for AD users with trusts. I thought we would have to issue some patch for client to switch the clients from using Kerberos for authentication to using LDAP. No need to. pam_ldap would go through LDAP bind automatically, that's why the proposal talks about attempting to obtain TGT in place of a user instead of proxying such LDAP bind back to AD DC. This would require us enforcing clear password bind over TLS/SSL but it is simpler to achieve. I am missing something. How a simple kinit would work? Can you please describe the sequence and workflow? I'm talking about the case when AD user logs in into IPA client using PuTTY from
Re: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts
On Tue, 28 May 2013, Dmitri Pal wrote: On 05/28/2013 04:29 PM, Alexander Bokovoy wrote: On Tue, 28 May 2013, Dmitri Pal wrote: On 05/28/2013 03:48 PM, Alexander Bokovoy wrote: On Tue, 28 May 2013, Dmitri Pal wrote: On 05/28/2013 07:50 AM, Alexander Bokovoy wrote: Hi, http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts = Overview = Since version 3.0 FreeIPA supports cross-realm trusts with Active Directory. In order to allow AD users to utilize services on IPA clients, up to date version of SSSD should be configured at the IPA client. In case it is not possible to install and configure SSSD 1.09, Active Directory users cannot access services on IPA clients. This feature is designed to bridge the gap and provide minimal compatibility level that allows to log-in to IPA clients for AD users. IPA clients will be able to use any reasonable nss_ldap/pam_ldap/sssd version. = Use Cases = Access to IPA client machine resources for AD users in case IPA client cannot utilize up to date version of SSSD with native support for IPA cross-realm trusts. = Design= Since IPA client is configured with the use of older SSSD or nss_ldap/pam_ldap, all work should be performed at the IPA master. Primary design decision is to provide a separate LDAP tree, similar to compat tree, that has following features: * information about both IPA and AD users can be queried; * it ispossible to enumerate members of IPA and AD groups; * authentication bind to IPA LDAP as AD users should automatically * trigger obtaining ticket from AD DC; in case TGT is obtained, * authentication bind should be treated as successful. From a client perspective, use of the separate LDAP tree is viewed as traditional nss_ldap/pam_ldap configuration. Proposed base for the LDAP tree: '''cn=users,cn=trust-accounts,dc=example,dc=com''' = Implementation = # IPA server sets SSSD configuration to 'ipa_server_mode = true' on install or upgrade # ipa-adtrust-install configures additional directory server plugin to serve trusted domains tree # Directory server plugin uses getpwnam_r(), getgrnam_r() and related calls to obtain information about AD user. For IPA users the information is fetched directly from the LDAP. # IPA KDC database driver adds MS-PAC information into ticket granting ticket for host/fqdn@REALM principal of IPA master. This is required to allow SSSD on IPA master to authenticate against AD using host/fqdn@REALM principal. For SSSD design see https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode = Feature Management = === UI === The feature is transparent and not exposed in UI === CLI === The feature is not directly exposed in CLI. IPA idrange management is expanded to specify idrange type (IPA local, AD trust, AD with winsync, IPA trust, ..) to affect the way how AD users SIDs are mapped to POSIX IDs. = Major configuration options and enablement = sssd.conf will have 'ipa_server_mode = true' set for IPA master. = Replication = No effect on replication. Since directory server plugin is only configured when ipa-adtrust-install is run, IPA masters may opt out from serving AD clients. = Updates and Upgrades = During upgrade of IPA master, sssd.conf should be updated to set 'ipa_server_mode = true'. = Dependencies = Depends on SSSD implementing IPA server mode (sssd 1.10.x) = External Impact = https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode = Backup and Restore = No external configuration files are affected = Test Plan = Testing the feature will require following: # Configure IPA to serve AD trusts # Establish trust with AD domain # Configure a client to use nss_ldap/pam_ldap against AD-compatible tree # Attempt to log-in to the client as AD user = RFE Author = [[User:Ab|ab]] ([[User talk:Ab|talk]]) Can you please explain how the older SSSD or other UNIX versions would use Kerberos for authentication? pam_krb5 should work as it is, as well as older SSSD, since any AD user attempting to connect using GSSAPI to IPA services will have cross-realm TGT issued for us by the trusting AD DC prior to that attempt. The whole idea was to make sure for old clients these users will look like normal users, via nss_ldap/SSSD. We still will need to configure principal mapping in /etc/krb5.conf like we do for AD users with trusts. I thought we would have to issue some patch for client to switch the clients from using Kerberos for authentication to using LDAP. No need to. pam_ldap would go through LDAP bind automatically, that's why the proposal talks about attempting to obtain TGT in place of a user instead of proxying such LDAP bind back to AD DC. This would require us enforcing clear password bind over TLS/SSL but it is simpler to achieve. I am missing something. How a simple kinit would work? Can you please describe the sequence and workflow? I'm talking about the case when AD user logs in into IPA client using PuTTY from Windows machine. In such case there is already service ticket and
