[Freeipa-users] ID Views without AD

Fri Feb 19 13:05:03 UTC 2016

On Fri, Feb 19, 2016 at 12:12:42PM +0000, Mike Kelly wrote:
> Ahha! I seem to have gotten somewhere now!
> 
> I just re-applied the view to my host, restarted sssd and cleared its

yes, that's what I meant earlier with the missing view entry in the
cache. SSSD tries to figure out if a view name changed at startup time
and if it happened it removes the old view data. This does not work
properly because of the  issue we have and hence SSSD needs some help by
either doing a fresh view name change with the fixed version or remove
the existing cache.

> cache, and it's now picking up my overridden UID and GID! (I had to
> manually add an entry for the overridden GID to /etc/group, because FreeIPA
> won't let me override the private user groups.)

yes, this is expected, but you do not have to add the group to
/etc/group but you can add a new group with the overridden GID to IPA as
well.

bye,
Sumit

(Alexander already commented on the questions below)

> 
> One odd caveat, but perhaps this is part of the design... if I do a `getent
> $IPA_UID` or `getent $OVERRIDE_UID`... both give the same output, my user
> with the overridden UID. I'd expect the first one to just give no result?
> 
> ----
> 
> One side question, though... now that I have done half of the work for an
> AD trust... is it possible for me to make my FreeIPA server into an AD
> controller for the one Windows box in my house? Some searching I did before
> indicated no, in part because Samba required Heimdal instead of MIT
> Kerberos... is that still true?
> 
> On Thu, Feb 18, 2016 at 12:21 PM Mike Kelly <pioto at pioto.org> wrote:
> 
> > Thanks for the quick reply.
> >
> > FWIW, I'm on CentOS 7, but I haven't yet tried to apply your test sssd
> > packages.
> >
> > I don't seem to have the "ldbadd" command on my client, either.
> >
> > Also, I tried running `sudo ipa-adtrust-install --add-sids -A pioto`, and
> > I see more in the logs now.
> >
> > But, I don't seem to be seeing my UID changing like I'd expect, and I seem
> > to no longer be able to run sudo on my client...
> >
> > If I unapply the view from my client's host, though, sudo again works as
> > expected. So, it's picking up... something... just not quite everything yet.
> >
> >
> > On Thu, Feb 18, 2016 at 10:28 AM Sumit Bose <sbose at redhat.com> wrote:
> >
> >> On Thu, Feb 18, 2016 at 11:26:58AM +0100, Sumit Bose wrote:
> >> > On Tue, Feb 16, 2016 at 04:23:10PM +0000, Mike Kelly wrote:
> >> > > >>  Thanks. Here's what is hopefully the relevant lines:
> >> > > >
> >> > > > I'm sorry, but these logs only capture how the original entry was
> >> > > searched, not the overrides. Can you capture the full logs since the
> >> sssd
> >> > > startup? Also please make sure the cache was invalidated prior to the
> >> > > request with sss_cache -E.
> >> > >
> >> > > Attached are the full logs since a restart of sssd.
> >> >
> >> > Thank you, the logs helped. The IPA client reads the idview at startup
> >> > time either from the cache or the IPA server. Since there is of course
> >> > no idview name saved in the cache of your client the name must be looked
> >> > up from the server. The lookup of the idview name is part of the request
> >> > which reads other data about the IPA domain and possible trusted
> >> > domains. Unfortunately the current code expects that e.g. the domain SID
> >> > of the IPA domain is defined before it proceeds to read the idview.
> >> >
> >> > This is of course a bug and I will try to fix it. If you would like to
> >> > try a work-around you can call ipa-adtrust-install on one of your IPA
> >> > servers. This will create the needed data on the server. It is
> >> > sufficient to call it on one server because the data will be replicated
> >> > to the other servers and since you currently not plan to add a trust to
> >> > a AD domain, you do not have to prepare additional services on other
> >> > server (with FreeIPA-4.2 this wouldn't even be necessary if you plan to
> >> > add a trust).
> >> >
> >> > If you can wait a day or two I'd be happy to prepare a SSSD test build
> >> > with a fix.
> >>
> >> It looks it was easier than I expected. You can find test packages for
> >> RHEL/CentOS-7 at
> >>
> >> http://koji.fedoraproject.org/koji/taskinfo?taskID=13035051
> >>
> >> (Please tell me if you need packages for a different platform)
> >>
> >> Before you upgrade the package on a client please run
> >>
> >> # ldbadd -H /var/lib/sss/db/cache_your.domain.name.ldb << EOF
> >> dn: cn=views,cn=sysdb
> >> viewName: default
> >> EOF
> >>
> >> Otherwise SSSD will not recognise the name change and still show the
> >> original values. As an alternative you can remove the cache completely
> >> before starting the new version or unapply the idview and apply it again
> >> on the server while you restart the new sssd version on the client after
> >> each change on the server. I'll try to think of a way to make this more
> >> easy without breaking the existing detection of a change in the idview
> >> name.
> >>
> >> HTH
> >>
> >> bye,
> >> Sumit
> >>
> >> >
> >> > bye,
> >> > Sumit
> >> >
> >> > >
> >> > > I ran these commands:
> >> > >
> >> > > systemctl stop sssd
> >> > >
> >> > > echo '----MARK----' >> /var/log/sssd/sssd_home.pioto.org.log # so I
> >> could
> >> > > mark were the restart happened
> >> > >
> >> > > sss_cache -E
> >> > >
> >> > > systemctl start sssd
> >> > >
> >> > > sss_cache -E
> >> > >
> >> > > id pioto
> >> > >
> >> > > ----
> >> > >
> >> > > I still don't see the override being applied. Possibly because of
> >> this line?
> >> > >
> >> > > (Tue Feb 16 11:12:27 2016) [sssd[be[home.pioto.org]]]
> >> > > [ipa_get_ad_override_send]
> >> > > (0x4000): View not defined, nothing to do.
> >> > >
> >> > > So, I get the feeling that, for whatever reason, sssd isn't correctly
> >> > > deciding that my id view applies to this host, or just isn't looking
> >> it up?
> >> > >
> >> > > Is there possibly some sort of extra configuration that I've missed
> >> to tell
> >> > > SSSD to apply these views? From what I can tell, it should just pick
> >> these
> >> > > up out of the box, from the configuration built by
> >> ipa-client-install...?
> >> >
> >> >
> >> > > --
> >> > > Manage your subscription for the Freeipa-users mailing list:
> >> > > https://www.redhat.com/mailman/listinfo/freeipa-users
> >> > > Go to http://freeipa.org for more info on the project
> >> >
> >> > --
> >> > Manage your subscription for the Freeipa-users mailing list:
> >> > https://www.redhat.com/mailman/listinfo/freeipa-users
> >> > Go to http://freeipa.org for more info on the project
> >>
> > --
> >
> > Mike Kelly
> >
> -- 
> 
> Mike Kelly