Hi folks,
I have a set of servers that CANNOT become enrolled IDM clients due to a vendor refusing to support this type of config.
This server fleet is directly bound to an AD system via the standard non-IPA "realm join ..." type commands
Since I can't bring these servers "into the fold" so to speak at the very least I would love to offset at least one potential future problem by seeing if I can help them configure sssd.conf on their local machines to use the same AD SID-to-UID algorithm (complete with custom ID Range values that we have enabled on the IPA master) so that they at least get the same UID and GID values for their AD users as the same user would get if they logged into the much larger fleet of IDM-managed servers.
Hope I'm asking the question properly -- in a nutshell I'm wondering how to trick a standalone sssd.conf file so that it uses the same SID-to-UID algorithm that an IDM master would use. This would at least let me get consistent UID/GID values across my fleet of enrolled vs. non-enrolled IDM clients ! Tips or advice appreciated even if the response is "heck no; you can't do that .. "
Regards, Chris
On Wed, Jun 28, 2017 at 01:03:45PM -0400, Chris Dagdigian via FreeIPA-users wrote:
Hi folks,
I have a set of servers that CANNOT become enrolled IDM clients due to a vendor refusing to support this type of config.
This server fleet is directly bound to an AD system via the standard non-IPA "realm join ..." type commands
Since I can't bring these servers "into the fold" so to speak at the very least I would love to offset at least one potential future problem by seeing if I can help them configure sssd.conf on their local machines to use the same AD SID-to-UID algorithm (complete with custom ID Range values that we have enabled on the IPA master) so that they at least get the same UID and GID values for their AD users as the same user would get if they logged into the much larger fleet of IDM-managed servers.
Hope I'm asking the question properly -- in a nutshell I'm wondering how to trick a standalone sssd.conf file so that it uses the same SID-to-UID algorithm that an IDM master would use. This would at least let me get consistent UID/GID values across my fleet of enrolled vs. non-enrolled IDM clients ! Tips or advice appreciated even if the response is "heck no; you can't do that .. "
So is the requirement absolutely to have the machines enrolled as part of the AD domain?
If not, have you considered pointing the clients towards the compat tree and using a plain LDAP setup, if your vendor supports that?
On Wed, Jun 28, 2017 at 08:22:12PM +0200, Jakub Hrozek via FreeIPA-users wrote:
On Wed, Jun 28, 2017 at 01:03:45PM -0400, Chris Dagdigian via FreeIPA-users wrote:
Hi folks,
I have a set of servers that CANNOT become enrolled IDM clients due to a vendor refusing to support this type of config.
This server fleet is directly bound to an AD system via the standard non-IPA "realm join ..." type commands
Since I can't bring these servers "into the fold" so to speak at the very least I would love to offset at least one potential future problem by seeing if I can help them configure sssd.conf on their local machines to use the same AD SID-to-UID algorithm (complete with custom ID Range values that we have enabled on the IPA master) so that they at least get the same UID and GID values for their AD users as the same user would get if they logged into the much larger fleet of IDM-managed servers.
Hope I'm asking the question properly -- in a nutshell I'm wondering how to trick a standalone sssd.conf file so that it uses the same SID-to-UID algorithm that an IDM master would use. This would at least let me get consistent UID/GID values across my fleet of enrolled vs. non-enrolled IDM clients ! Tips or advice appreciated even if the response is "heck no; you can't do that .. "
So is the requirement absolutely to have the machines enrolled as part of the AD domain?
If not, have you considered pointing the clients towards the compat tree and using a plain LDAP setup, if your vendor supports that?
What Jakub pointed out would be the way which currently would work. Defining the ID ranges in sssd.conf in a completely flexible way is currently not possible. There is https://pagure.io/SSSD/sssd/issue/2651 which tracks this feature although the title might be a bit misleading.
bye, Sumit
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
Jakub Hrozek via FreeIPA-users wrote:
If not, have you considered pointing the clients towards the compat tree and using a plain LDAP setup, if your vendor supports that?
Appreciate the replies to even a non-IPA usage question. This list has a tremendous signal:noise ratio.
The info above sounds promising but I don't quite understand it. Is there a chapter in the IDM Admin Guide you can point me to to read up on or some other reference I can check out? Thanks!
Chris
On Thu, Jun 29, 2017 at 08:41:25AM -0400, Chris Dagdigian wrote:
Jakub Hrozek via FreeIPA-users wrote:
If not, have you considered pointing the clients towards the compat tree and using a plain LDAP setup, if your vendor supports that?
Appreciate the replies to even a non-IPA usage question. This list has a tremendous signal:noise ratio.
The info above sounds promising but I don't quite understand it. Is there a chapter in the IDM Admin Guide you can point me to to read up on or some other reference I can check out? Thanks!
I'm sorry, I didn't find a chapter in the IDM guide, but I found: https://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts which has some examples.
freeipa-users@lists.fedorahosted.org