On Fri, Jan 11, 2019 at 12:24 PM Sumit Bose <sbose@redhat.com> wrote:
On Fri, Jan 11, 2019 at 11:03:12AM -0500, vadud3@gmail.com wrote:
> On Fri, Jan 11, 2019 at 6:50 AM Sumit Bose <sbose@redhat.com> wrote:
>
> > On Wed, Jan 09, 2019 at 12:47:34PM -0500, vadud3@gmail.com wrote:
> > > Looking for suggestion on ID mapping.
> > >
> > > I need to point to a ID provider over proxy
> > >
> > > I have not found a concrete solution or some hint about how to setup a
> > > proxy to a ID provider and how sssd can point to that proxy for ID
> > mapping.
> >
> > Can you rephrase your question? 'ID provider over proxy' should like you
> > want some more details about SSSD's proxy provider as described in the
> > sssd.conf man page. But this is unrelated to what I associate typically
> > with 'ID mapping'. Please give a bit more details about what you are
> > trying to achieve.
> >
> >
> I am looking for a ID mapping solution. I do see following providers.
>
>            “proxy”: Support a legacy NSS provider.
>
>            “local”: SSSD internal provider for local users (DEPRECATED).
>
>            “files”: FILES provider. See sssd-files(5) for more information
> on how to mirror local users and groups into SSSD.
>
>            “ldap”: LDAP provider. See sssd-ldap(5) for more information on
> configuring LDAP.
>
>            “ipa”: FreeIPA and Red Hat Enterprise Identity Management
> provider. See sssd-ipa(5) for more information on
>            configuring FreeIPA.
>
>            “ad”: Active Directory provider. See sssd-ad(5) for more
> information on configuring Active Directory.
>
> I am looking for a suggestion.
>            ad - won't work as we will not be provided Administrator password

If the data for all users and groups is stored in AD this would be the
most recommended provider. You do not need the Administrator password
for SSSD to operate but a "normal" account which can read user and group
data is sufficient. Typically this is machine account which is created
when you join the Linux host to the AD domain.

I will check it out Monday at work. But I do remember trying to join with realmd and it was asking
for Administrator password. I also tried with -U <mycuid> and it did not let me join.

I have to see if IT is willing to provide us a "machine account" to join our Linux servers 

if that is a success that AD SID will automatically used to generate UID/GID, I think, correct?

Assuming AD can be used as auth and id provider, then I will need to find a solution to setup a proxy to AD, so all my 100+ servers
do not need to setup with firewall and manage access. This last piece deserves a separate new email, so not looking for an answer for this.

Appreciate your help!



If you use realmd for joining the domain realmd will create a basic SSSD
configuration automatically.

To join a domain you do not need the Administrator account either.
Please check the AD documentation how to assign privileges to a "normal"
account so that it can be use to join machines,

>            ldap - won't work as IT says not to use LDAP and use kerberos
> instead for all things UNIX auth

You can use 'auth_provider = krb5' with 'id_provider = ldap'

>                    and to use /etc/passwd for id (yikes, we have 100s of
> servers to manage)
>            files - I am not sure how to have a central files for all
> accounts
>            local - seems deprecated
>            proxy - I am not sure how to set that up, but seems like easier
> for a central ID provider?

It depends what your central ID provider is and if there already is an
nss module for this provider. If your central ID provider is AD please
see my comments there.

HTH

bye,
Sumit

>
> Please advise
>
>
>
>
>
>
>
> > bye,
> > Sumit
> >
> > >
> > > All my servers are CentOS 7.
> > >
> > >
> > > --
> > > Asif Iqbal
> > > PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
> > > A: Because it messes up the order in which people normally read text.
> > > Q: Why is top-posting such a bad thing?
> >
> > > _______________________________________________
> > > sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> > > To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
> > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives:
> > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> > _______________________________________________
> > sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> > To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> >
>
>
> --
> Asif Iqbal
> PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?

> _______________________________________________
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
_______________________________________________
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org


--
Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?