Re: [Freeipa-users] ID Views without AD
On Fri, Feb 19, 2016 at 12:12:42PM +, 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 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 wrote: > > > >> On Thu, Feb 18, 2016 at 11:26:58AM +0100, Sumit Bose wrote: > >> > On Tue, Feb 16, 2016 at 04:23:10PM +, 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,
Re: [Freeipa-users] ID Views without AD
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),140340 [root@data ~]# getent passwd 140340 admin:*:140340:140340:Administrator:/home/admin:/bin/bash [root@data ~]# getent passwd admin admin:*:140340:140340: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),140340(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 140340 admins:*:140340: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 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
Re: [Freeipa-users] ID Views without AD
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 -- 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
Re: [Freeipa-users] ID Views without AD
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? 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 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 wrote: > >> On Thu, Feb 18, 2016 at 11:26:58AM +0100, Sumit Bose wrote: >> > On Tue, Feb 16, 2016 at 04:23:10PM +, 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 ext
Re: [Freeipa-users] ID Views without AD
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 wrote: > On Thu, Feb 18, 2016 at 11:26:58AM +0100, Sumit Bose wrote: > > On Tue, Feb 16, 2016 at 04:23:10PM +, 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 -- 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
Re: [Freeipa-users] ID Views without AD
On Thu, Feb 18, 2016 at 11:26:58AM +0100, Sumit Bose wrote: > On Tue, Feb 16, 2016 at 04:23:10PM +, 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 -- 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
Re: [Freeipa-users] ID Views without AD
On Tue, Feb 16, 2016 at 04:23:10PM +, 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. 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
Re: [Freeipa-users] ID Views without AD
Digging into the code more, I wonder if this is a bug in sssd? https://github.com/SSSD/sssd/blob/sssd-1_13_0/src/db/sysdb.h#L465-L474 -- NULL is treated as the "default" view, as is the literal string "default", in is_default_view(...). https://github.com/SSSD/sssd/blob/sssd-1_13_0/src/providers/ipa/ipa_views.c#L274-L284 - NULL is treated as "View not defined, nothing to do", in ipa_get_ad_override_send(...). Seems possible that, if that first condition is removed, things could work like I'd expect them to? But, I'm just grasping at straws at this point... is there possibly some config field I can use to force the view name? I feel like the code that's supposed to detect the view name isn't triggering correctly in my case, and that's what is triggering the issue... On Tue, Feb 16, 2016 at 11:23 AM 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. > > 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...? > -- 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
Re: [Freeipa-users] ID Views without AD
On Thu, Feb 11, 2016 at 11:17:01AM +, Mike Kelly wrote: > On Thu, Feb 11, 2016 at 3:21 AM Alexander Bokovoy > wrote: > > > On Wed, 10 Feb 2016, Mike Kelly wrote: > > >On Wed, Feb 10, 2016 at 3:19 AM Alexander Bokovoy > > >wrote: > > > > > >> On Wed, 10 Feb 2016, Mike Kelly wrote: > > >> > > >> >Is there some extra logging I can turn on to see why this ID View isn't > > >> >being applied like I would expect? Or perhaps some extra bit of > > >> >configuration I missed? > > >> Level 7 or 9 debug logs in SSSD on the client might help. > > >> > > > > > >Thanks. > > > > > >Here's what looks like the relevant bits in /var/log/sssd/sssd_nss.log, > > >after I ran `sss_cache -E ; id pioto`: > > Please provide content of sssd_.log, this is where the actual > > work is done when user information is obtained and processed. > > sssd_nss.log is merely a requestor. > > > > 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. -- 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
Re: [Freeipa-users] ID Views without AD
On Wed, Feb 10, 2016 at 3:19 AM Alexander Bokovoy wrote: > On Wed, 10 Feb 2016, Mike Kelly wrote: > > >Is there some extra logging I can turn on to see why this ID View isn't > >being applied like I would expect? Or perhaps some extra bit of > >configuration I missed? > Level 7 or 9 debug logs in SSSD on the client might help. > Thanks. Here's what looks like the relevant bits in /var/log/sssd/sssd_nss.log, after I ran `sss_cache -E ; id pioto`: (Wed Feb 10 15:06:45 2016) [sssd[nss]] [nss_cmd_getbynam] (0x0400): Running command [17] with input [pioto]. (Wed Feb 10 15:06:45 2016) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): name 'pioto' matched without domain, user is pioto (Wed Feb 10 15:06:45 2016) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [pioto] from [] (Wed Feb 10 15:06:45 2016) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [pi...@home.pioto.org] (Wed Feb 10 15:06:45 2016) [sssd[nss]] [get_dp_name_and_id] (0x0400): Not a LOCAL view, continuing with provided values. (Wed Feb 10 15:06:45 2016) [sssd[nss]] [sss_dp_issue_request] (0x0400): Issuing request for [0x7f9b482220e0:1:pi...@home.pioto.org] (Wed Feb 10 15:06:45 2016) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): Creating request for [home.pioto.org][4097][1][name=pioto] (Wed Feb 10 15:06:45 2016) [sssd[nss]] [sss_dp_internal_get_send] (0x0400): Entering request [0x7f9b482220e0:1:pi...@home.pioto.org] (Wed Feb 10 15:06:45 2016) [sssd[nss]] [sss_dp_get_reply] (0x1000): Got reply from Data Provider - DP error code: 0 errno: 0 error message: Success (Success) (Wed Feb 10 15:06:45 2016) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [pi...@home.pioto.org] (Wed Feb 10 15:06:45 2016) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0400): Returning info for user [pi...@home.pioto.org] (Wed Feb 10 15:06:45 2016) [sssd[nss]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x7f9b482220e0:1:pi...@home.pioto.org] (Wed Feb 10 15:06:45 2016) [sssd[nss]] [nss_cmd_getbyid] (0x0400): Running command [34] with id [140341]. (Wed Feb 10 15:06:45 2016) [sssd[nss]] [nss_cmd_getgrgid_search] (0x0100): Requesting info for [1403400...@home.pioto.org] So, if I'm reading that right, it looks like we first query the server to find the user with name 'pioto', and then get back a response containing my IPA-assigned UID, and do a further lookup on that... it mentions "Not a LOCAL view, ...", but I'm not sure that's related? So, I wonder if there's some bit of client-side configuration that I'm missing? But, the bit that I see in /var/log/sssd/sssd_home.pioto.org.log seems to match up with what I can see in LDAP: (Wed Feb 10 13:09:52 2016) [sssd[be[home.pioto.org]]] [dp_copy_options_ex] (0x0400): Option ipa_views_search_base has value cn=views,cn=accounts,dc=home,dc=pioto,dc=org >I'm running a pair of CentOS 7 boxes, one acting as the FreeIPA server, and > >the other is the "legacy" box I want to shim FreeIPA into... > ID Views are only applied on machines where you have SSSD that supports > them, just to make sure. > Thanks. Both server and client are running: $ sssd --version 1.13.0 -- 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
Re: [Freeipa-users] ID Views without AD
On Thu, Feb 11, 2016 at 3:21 AM Alexander Bokovoy wrote: > On Wed, 10 Feb 2016, Mike Kelly wrote: > >On Wed, Feb 10, 2016 at 3:19 AM Alexander Bokovoy > >wrote: > > > >> On Wed, 10 Feb 2016, Mike Kelly wrote: > >> > >> >Is there some extra logging I can turn on to see why this ID View isn't > >> >being applied like I would expect? Or perhaps some extra bit of > >> >configuration I missed? > >> Level 7 or 9 debug logs in SSSD on the client might help. > >> > > > >Thanks. > > > >Here's what looks like the relevant bits in /var/log/sssd/sssd_nss.log, > >after I ran `sss_cache -E ; id pioto`: > Please provide content of sssd_.log, this is where the actual > work is done when user information is obtained and processed. > sssd_nss.log is merely a requestor. > Thanks. Here's what is hopefully the relevant lines: (Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]] [sdap_search_user_next_base] (0x0400): Searching for users with base [cn=accounts,dc=home,dc=pioto,dc=org] (Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(uid=pioto)(objectclass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0 ][cn=accounts,dc=home,dc=pioto,dc=org]. (Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]] [sdap_parse_entry] (0x1000): OriginalDN: [uid=pioto,cn=users,cn=accounts,dc=home,dc=pioto,dc=org]. (Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set (Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]] [sdap_search_user_process] (0x0400): Search for users, returned 1 results. (Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]] [sdap_save_user] (0x0400): Save user (Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]] [sdap_attrs_get_sid_str] (0x1000): No [objectSIDString] attribute. [0][Success] (Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]] [sdap_get_primary_name] (0x0400): Processing object pioto (Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]] [sdap_save_user] (0x0400): Processing user pioto (Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]] [sdap_save_user] (0x0400): Adding original memberOf attributes to [pioto]. (Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]] [sdap_save_user] (0x0400): Adding user principal [pi...@home.pioto.org] to attributes of [pioto]. (Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]] [sdap_save_user] (0x0400): Storing info for user pioto (Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Success) -- so, looks like i don't see any evidence of an id view being searched for or applied? (Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]] [be_get_account_info] (0x0200): Got request for [0x1002][1][idnumber=140341] (Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]] [sdap_get_groups_next_base] (0x0400): Searching for groups with base [cn=accounts,dc=home,dc=pioto,dc=org] (Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(gidNumber=140341)(|(objectClass=ipaUserGroup)(objectClass=posixGroup ))(cn=*)(&(gidNumber=*)(!(gidNumber=0][cn=accounts,dc=home,dc=pioto,dc=org]. -- and here, looks like nss is requesting the details from my FreeIPA default GID... The only log entries I see in /var/log/sssd/sssd_.log that are related to views seem to be from when I last restarted sssd: (Wed Feb 10 13:09:52 2016) [sssd[be[home.pioto.org]]] [dp_get_options] (0x0400): Option ipa_views_search_base has no value (Wed Feb 10 13:09:52 2016) [sssd[be[home.pioto.org]]] [ipa_get_id_options] (0x0100): Option ipa_views_search_base set to cn=views,cn=accounts,dc=home,dc=pioto,dc=org (Wed Feb 10 13:09:52 2016) [sssd[be[home.pioto.org]]] [common_parse_search_base] (0x0100): Search base added: [IPA_VIEWS][cn=views,cn=accounts,dc=home,dc=pioto,dc=org][SUBTREE][] (Wed Feb 10 13:09:52 2016) [sssd[be[home.pioto.org]]] [sdap_get_map] (0x0400): Option ipa_view_class has value nsContainer (Wed Feb 10 13:09:52 2016) [sssd[be[home.pioto.org]]] [sdap_get_map] (0x0400): Option ipa_view_name has value cn (Wed Feb 10 13:09:52 2016) [sssd[be[home.pioto.org]]] [sssm_ipa_id_init] (0x0020): Cannot find view name in the cache. Will do online lookup later. (Wed Feb 10 13:09:52 2016) [sssd[be[home.pioto.org]]] [dp_copy_options_ex] (0x0400): Option ipa_views_search_base has value cn=views,cn=accounts,dc=home,dc=pioto,dc=org (Wed Feb 10 13:09:52 2016) [sssd[be[home.pioto.org]]] [dp_copy_options_ex] (0x0400): Option ipa_views_search_base has value cn=views,cn=accounts,dc=home,dc=pioto,dc=org When I search LDAP under that search base, I get 3 DNs I'd expect to see: dn: cn=views,cn=accounts,dc=home,dc=pioto,dc=org dn: cn=oldservers,cn=views,cn=accounts,dc=h
Re: [Freeipa-users] ID Views without AD
On Thu, Feb 11, 2016 at 10:21:37AM +0200, Alexander Bokovoy wrote: > On Wed, 10 Feb 2016, Mike Kelly wrote: > >On Wed, Feb 10, 2016 at 3:19 AM Alexander Bokovoy > >wrote: > > > >>On Wed, 10 Feb 2016, Mike Kelly wrote: > >> > >>>Is there some extra logging I can turn on to see why this ID View isn't > >>>being applied like I would expect? Or perhaps some extra bit of > >>>configuration I missed? > >>Level 7 or 9 debug logs in SSSD on the client might help. > >> > > > >Thanks. > > > >Here's what looks like the relevant bits in /var/log/sssd/sssd_nss.log, > >after I ran `sss_cache -E ; id pioto`: > Please provide content of sssd_.log, this is where the actual > work is done when user information is obtained and processed. > sssd_nss.log is merely a requestor. This wiki page might be helpful: https://fedorahosted.org/sssd/wiki/Troubleshooting -- 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
Re: [Freeipa-users] ID Views without AD
On Wed, 10 Feb 2016, Mike Kelly wrote: On Wed, Feb 10, 2016 at 3:19 AM Alexander Bokovoy wrote: On Wed, 10 Feb 2016, Mike Kelly wrote: >Is there some extra logging I can turn on to see why this ID View isn't >being applied like I would expect? Or perhaps some extra bit of >configuration I missed? Level 7 or 9 debug logs in SSSD on the client might help. Thanks. Here's what looks like the relevant bits in /var/log/sssd/sssd_nss.log, after I ran `sss_cache -E ; id pioto`: Please provide content of sssd_.log, this is where the actual work is done when user information is obtained and processed. sssd_nss.log is merely a requestor. -- / Alexander Bokovoy -- 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
Re: [Freeipa-users] ID Views without AD
On Wed, 10 Feb 2016, Mike Kelly wrote: Hi, I'm attempting to use ID Views as a shim, to allow me to have an existing host work with FreeIPA without having to re-chown many many files. Here's my basic strategy, and where things seem to be failing: For any truly local groups (e.g. for specific local services), I continue to manage those in /etc/groups For any users, they should be managed in FreeIPA, especially the password and SSH Pubkeys. But, they should continue to appear with their old UIDs and GIDs on the server. This means the user doesn't exist in /etc/passwd or /etc/shadow anymore (or the local password would be used, as I understand it). An ID View is created, applied to this host, and has a user override added to override the UID and GID of the user. But, when I do this, I continue to see the usual UID and GID in the output of `id $USER`, etc, even after running `sss_cache -E` and `systemctl restart sssd`. Is there some extra logging I can turn on to see why this ID View isn't being applied like I would expect? Or perhaps some extra bit of configuration I missed? Level 7 or 9 debug logs in SSSD on the client might help. I'm running a pair of CentOS 7 boxes, one acting as the FreeIPA server, and the other is the "legacy" box I want to shim FreeIPA into... ID Views are only applied on machines where you have SSSD that supports them, just to make sure. -- / Alexander Bokovoy -- 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
[Freeipa-users] ID Views without AD
Hi, I'm attempting to use ID Views as a shim, to allow me to have an existing host work with FreeIPA without having to re-chown many many files. Here's my basic strategy, and where things seem to be failing: For any truly local groups (e.g. for specific local services), I continue to manage those in /etc/groups For any users, they should be managed in FreeIPA, especially the password and SSH Pubkeys. But, they should continue to appear with their old UIDs and GIDs on the server. This means the user doesn't exist in /etc/passwd or /etc/shadow anymore (or the local password would be used, as I understand it). An ID View is created, applied to this host, and has a user override added to override the UID and GID of the user. But, when I do this, I continue to see the usual UID and GID in the output of `id $USER`, etc, even after running `sss_cache -E` and `systemctl restart sssd`. Is there some extra logging I can turn on to see why this ID View isn't being applied like I would expect? Or perhaps some extra bit of configuration I missed? I'm running a pair of CentOS 7 boxes, one acting as the FreeIPA server, and the other is the "legacy" box I want to shim FreeIPA into... Thanks. -- 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
