<div dir="ltr">Thanks.<div><br></div><div>Ok, one final concern, though, I guess I didn't resolve the issues with sudo...</div><div><br></div><div><div><span style="line-height:1.5">[root@data ~]</span># sudo -l -U pioto</div><div>User pioto is not allowed to run sudo on data.</div></div><div><br></div><div>But, huh, after running these few commands, now I can?</div><div><br></div><div><div>[root@data ~]# id pioto</div><div>uid=1001(pioto) gid=1001(pioto) groups=1001(pioto),991(libvirt),988(docker),1005(backups),1009(media),1403400000</div><div>[root@data ~]# getent passwd 1403400000</div><div>admin:*:1403400000:1403400000:Administrator:/home/admin:/bin/bash</div><div>[root@data ~]# getent passwd admin</div><div>admin:*:1403400000:1403400000:Administrator:/home/admin:/bin/bash</div><div>[root@data ~]# id pioto</div><div>uid=1001(pioto) gid=1001(pioto) groups=1001(pioto),991(libvirt),988(docker),1005(backups),1009(media),1403400000(admins)</div><div>[root@data ~]# sudo -l -U pioto</div><div>Matching Defaults entries for pioto on this host:</div><div> requiretty, !visiblepw, always_set_home, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR</div><div> LS_COLORS", env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE LC_IDENTIFICATION</div><div> LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL</div><div> LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY", secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin</div><div><br></div><div>User pioto may run the following commands on this host:</div><div> (ALL : ALL) ALL</div></div><div><span style="line-height:1.5">[root@data ~]# getent group 1403400000</span><br></div><div><div>admins:*:1403400000:admin,pioto</div></div><div><br></div><div>----</div><div><br></div><div>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?</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Feb 19, 2016 at 7:20 AM Alexander Bokovoy <<a href="mailto:abokovoy@redhat.com">abokovoy@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, 19 Feb 2016, Mike Kelly wrote:<br>
>Ahha! I seem to have gotten somewhere now!<br>
><br>
>I just re-applied the view to my host, restarted sssd and cleared its<br>
>cache, and it's now picking up my overridden UID and GID! (I had to<br>
>manually add an entry for the overridden GID to /etc/group, because FreeIPA<br>
>won't let me override the private user groups.)<br>
><br>
>One odd caveat, but perhaps this is part of the design... if I do a `getent<br>
>$IPA_UID` or `getent $OVERRIDE_UID`... both give the same output, my user<br>
>with the overridden UID. I'd expect the first one to just give no result?<br>
That's by design.<br>
<br>
>----<br>
>One side question, though... now that I have done half of the work for an<br>
>AD trust... is it possible for me to make my FreeIPA server into an AD<br>
>controller for the one Windows box in my house? Some searching I did before<br>
>indicated no, in part because Samba required Heimdal instead of MIT<br>
>Kerberos... is that still true?<br>
Yes and no. FreeIPA cannot be made an AD controller and even when we<br>
complete porting Samba AD to use MIT Kerberos, that will not change as<br>
Samba AD is using its own, completely separate, data store and cannot be<br>
made using an external LDAP server for that. Samba AD is a special mode<br>
in Samba, different from a traditional domain controller mode used by<br>
FreeIPA.<br>
<br>
So while you are able to join your Windows machine to Samba AD with<br>
Heimdal now or with MIT Kerberos in future, this will be a join to a<br>
totally separate domain.<br>
<br>
<br>
--<br>
/ Alexander Bokovoy<br>
</blockquote></div><div dir="ltr">-- <br></div><div dir="ltr"><p dir="ltr">Mike Kelly</p>
</div>