Thanks.

Ok, one final concern, though, I guess I didn't resolve the issues with
sudo...

[root@data ~]# sudo -l -U pioto
User pioto is not allowed to run sudo on data.

But, huh, after running these few commands, now I can?

[root@data ~]# id pioto
uid=1001(pioto) gid=1001(pioto)
groups=1001(pioto),991(libvirt),988(docker),1005(backups),1009(media),1403400000
[root@data ~]# getent passwd 1403400000
admin:*:1403400000:1403400000:Administrator:/home/admin:/bin/bash
[root@data ~]# getent passwd admin
admin:*:1403400000:1403400000:Administrator:/home/admin:/bin/bash
[root@data ~]# id pioto
uid=1001(pioto) gid=1001(pioto)
groups=1001(pioto),991(libvirt),988(docker),1005(backups),1009(media),1403400000(admins)
[root@data ~]# sudo -l -U pioto
Matching Defaults entries for pioto on this host:
    requiretty, !visiblepw, always_set_home, env_reset, env_keep="COLORS
DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR
    LS_COLORS", env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS
LC_CTYPE", env_keep+="LC_COLLATE LC_IDENTIFICATION
    LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY LC_NAME LC_NUMERIC
LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL
    LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin

User pioto may run the following commands on this host:
    (ALL : ALL) ALL
[root@data ~]# getent group 1403400000
admins:*:1403400000:admin,pioto

----

Is there maybe some other cache that `sss_cache -E` isn't clearing? Or some
other reason it didn't properly fetch the "admins" group until I looked up
the "admin" user?


On Fri, Feb 19, 2016 at 7:20 AM Alexander Bokovoy <aboko...@redhat.com>
wrote:

> On Fri, 19 Feb 2016, 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
> >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.)
> >
> >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?
> That's by design.
>
> >----
> >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?
> Yes and no. FreeIPA cannot be made an AD controller and even when we
> complete porting Samba AD to use MIT Kerberos, that will not change as
> Samba AD is using its own, completely separate, data store and cannot be
> made using an external LDAP server for that. Samba AD is a special mode
> in Samba, different from a traditional domain controller mode used by
> FreeIPA.
>
> So while you are able to join your Windows machine to Samba AD with
> Heimdal now or with MIT Kerberos in future, this will be a join to a
> totally separate domain.
>
>
> --
> / Alexander Bokovoy
>
-- 

Mike Kelly
-- 
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

Reply via email to