Re: [Freeipa-devel] KDC proxy implementation specs
Dne 29.5.2015 v 08:07 Nathaniel McCallum napsal(a): On Fri, 2015-05-29 at 08:02 +0200, Jan Cholasta wrote: Dne 28.5.2015 v 16:48 Nathaniel McCallum napsal(a): On Thu, 2015-05-28 at 16:34 +0200, Christian Heimes wrote: Jan has suggested to ipaConfigString=kdcProxyEnabled in cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc instead of ipaConfigString=enabledService in cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc. It makes sense to me. After all MS-KKDCP is just another transport for the KDC. [4] There may be a security concern here if we aren't careful. I think I'm in favor of KDCPROXY since it is a different application. What concern would that be? It has been already established that KDC proxy is not a different application, but rather a subcomponent of KDC in the other thread. Accidental exposure of something else in cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc. My fear comes from the fact that in order to make this work we have to expose stuff in cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc to apache. These kind of cross -domain security allowances always raises red flags for me. Well, the only exposed thing would be ipaConfigString, which always has an enabledService value for KDC and optionally would have kdcProxyEnabled value if KDC proxy is enabled. IMO if someone wants to put something sensitive in there, they should use a different attribute anyway. Don't cross the streams... it would be bad. :) Unless Zuul comes into the picture. Nathaniel -- Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] KDC proxy implementation specs
On Fri, 2015-05-29 at 08:11 +0200, Jan Cholasta wrote: Dne 29.5.2015 v 08:07 Nathaniel McCallum napsal(a): On Fri, 2015-05-29 at 08:02 +0200, Jan Cholasta wrote: Dne 28.5.2015 v 16:48 Nathaniel McCallum napsal(a): On Thu, 2015-05-28 at 16:34 +0200, Christian Heimes wrote: Jan has suggested to ipaConfigString=kdcProxyEnabled in cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc instead of ipaConfigString=enabledService in cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc. It makes sense to me. After all MS-KKDCP is just another transport for the KDC. [4] There may be a security concern here if we aren't careful. I think I'm in favor of KDCPROXY since it is a different application. What concern would that be? It has been already established that KDC proxy is not a different application, but rather a subcomponent of KDC in the other thread. Accidental exposure of something else in cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc. My fear comes from the fact that in order to make this work we have to expose stuff in cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc to apache. These kind of cross -domain security allowances always raises red flags for me. Well, the only exposed thing would be ipaConfigString, which always has an enabledService value for KDC and optionally would have kdcProxyEnabled value if KDC proxy is enabled. IMO if someone wants to put something sensitive in there, they should use a different attribute anyway. So say we now. Then, five years from now, when this conversation is a distant memory (if that), someone will think it is a good idea to do something stupid. :) Don't cross the streams... it would be bad. :) Unless Zuul comes into the picture. Is Zuul the intern in 2020 that exposes bad stuff? Nathaniel -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] KDC proxy implementation specs
Dne 28.5.2015 v 16:48 Nathaniel McCallum napsal(a): On Thu, 2015-05-28 at 16:34 +0200, Christian Heimes wrote: Jan has suggested to ipaConfigString=kdcProxyEnabled in cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc instead of ipaConfigString=enabledService in cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc. It makes sense to me. After all MS-KKDCP is just another transport for the KDC. [4] There may be a security concern here if we aren't careful. I think I'm in favor of KDCPROXY since it is a different application. What concern would that be? It has been already established that KDC proxy is not a different application, but rather a subcomponent of KDC in the other thread. -- Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] KDC proxy implementation specs
Hello, thanks you for your input. The former thread has 58 messages in total. Since last Friday we have came to an agreement in most points. I like to some up our decisions and focus on some minor details. decisions - python-kdcproxy will be installed as a dependency of freeipa-server. There won't be a separate freeipa-server-kdcproxy package. That may or may not change in the future. The decision is out of scope for 4.2.0. [1] KDC proxy support will be enabled by default. The config files and LDAP settings will be created by ipa-server-install, ipa-server-upgrade and ipa-replica-install. The enabled/disabled switch will be stored per-replica in the cn=masters,cn=ipa,cn=etc tree. An API and CLI tool for management is postponed. [2] For now we settle for some doc examples that use the ipa-ldap-updater as suggested by Alex. [3] open for discussion --- Jan has suggested to ipaConfigString=kdcProxyEnabled in cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc instead of ipaConfigString=enabledService in cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc. It makes sense to me. After all MS-KKDCP is just another transport for the KDC. [4] Martin Basti suggested a different keytab and principal for kdcproxy. [5] The keytab is only required for GSSAPI bind to lookup the state of the enabled/disabled switch. The current patch uses the same keytab as webgui. A new principal separates kdcproxy more cleanly and allows for fine-grained ACIs. It is also more future proof. In the future we may want to move kdcproxy from an Apache WSGI app to a separate service. A dedicated Twisted or asyncio daemon could handle more load. A separate keytab is easy to implement, too. I looked at the code in HTTPInstance.__create_http_keytab(). For the ACI I plan to add a new permission 'System: Read IPA Config String' and make the principal a direct memberOf of it. We don't have service roles yet. cn=roles,cn=accounts look like end user roles to me. The new ACI in cn=masters,cn=ipa,cn=etc will grant read, search and compare permission: (targetfilter = (objectClass=nsContainer))(targetattr = cn || objectClass || ipaConfigString)(version 3.0; acl Read IPA Config String; allow (read, search, compare) groupdn = ldap:///cn=System: Read IPA Config String,cn=permissions,cn=pbac,dc=ipa,dc=example;) I should be able to modify and test my patch in a matter of a couple of hours. Christian [1] http://www.redhat.com/archives/freeipa-devel/2015-May/msg00535.html [2] http://www.redhat.com/archives/freeipa-devel/2015-May/msg00555.html [3] http://www.redhat.com/archives/freeipa-devel/2015-May/msg00533.html [4] http://www.redhat.com/archives/freeipa-devel/2015-May/msg00543.html [5] http://www.redhat.com/archives/freeipa-devel/2015-May/msg00539.html signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] KDC proxy implementation specs
On Thu, 2015-05-28 at 10:48 -0400, Nathaniel McCallum wrote: On Thu, 2015-05-28 at 16:34 +0200, Christian Heimes wrote: Hello, thanks you for your input. The former thread has 58 messages in total. Since last Friday we have came to an agreement in most points. I like to some up our decisions and focus on some minor details. decisions - python-kdcproxy will be installed as a dependency of freeipa-server. There won't be a separate freeipa-server-kdcproxy package. That may or may not change in the future. The decision is out of scope for 4.2.0. [1] KDC proxy support will be enabled by default. The config files and LDAP settings will be created by ipa-server-install, ipa-server-upgrade and ipa-replica-install. The enabled/disabled switch will be stored per-replica in the cn=masters,cn=ipa,cn=etc tree. An API and CLI tool for management is postponed. [2] For now we settle for some doc examples that use the ipa-ldap-updater as suggested by Alex. [3] open for discussion --- Jan has suggested to ipaConfigString=kdcProxyEnabled in cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc instead of ipaConfigString=enabledService in cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc. It makes sense to me. After all MS-KKDCP is just another transport for the KDC. [4] There may be a security concern here if we aren't careful. I think I'm in favor of KDCPROXY since it is a different application. Martin Basti suggested a different keytab and principal for kdcproxy. [5] The keytab is only required for GSSAPI bind to lookup the state of the enabled/disabled switch. The current patch uses the same keytab as webgui. A new principal separates kdcproxy more cleanly and allows for fine-grained ACIs. It is also more future proof. It may also have auditing benefits now that we are beginning to think about the A in FreeIPA. We can't have 2 different keytabs with the same principal name. If we need privilege separation we'll have to work on integrating GSS-Proxy and give the keytab only to GSS-Proxy leaving it off the hands of both the framework, the proxy, and apache itself. Although to be honest I do not see why the proxy need access to the keytab at all, can we simply run it as a wsgi application under a different user and prevent it from accessing the apache keytab at all ? In the future we may want to move kdcproxy from an Apache WSGI app to a separate service. A dedicated Twisted or asyncio daemon could handle more load. A separate keytab is easy to implement, too. I looked at the code in HTTPInstance.__create_http_keytab(). An apache module would also provide similar benefits. I'm not sure I necessarily want to stick with python here if we're optimizing for performance. Another option would be to add it to the KDC itself and proxy through Apache like we do for Tomcat. MIT might like that option. What do we need the keytab for ? Is it just in order to authenticate and read if the service is enabled ? Can we make that information available anonymously ? For the ACI I plan to add a new permission 'System: Read IPA Config String' and make the principal a direct memberOf of it. We don't have service roles yet. cn=roles,cn=accounts look like end user roles to me. The new ACI in cn=masters,cn=ipa,cn=etc will grant read, search and compare permission: (targetfilter = (objectClass=nsContainer))(targetattr = cn || objectClass || ipaConfigString)(version 3.0; acl Read IPA Config String; allow (read, search, compare) groupdn = ldap:///cn=System: Read IPA Config String,cn=permissions,cn=pbac,dc=ipa,dc=example;) I should be able to modify and test my patch in a matter of a couple of hours. Christian [1] http://www.redhat.com/archives/freeipa-devel/2015-May/msg00535.html [2] http://www.redhat.com/archives/freeipa-devel/2015-May/msg00555.html [3] http://www.redhat.com/archives/freeipa-devel/2015-May/msg00533.html [4] http://www.redhat.com/archives/freeipa-devel/2015-May/msg00543.html [5] http://www.redhat.com/archives/freeipa-devel/2015-May/msg00539.html -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] KDC proxy implementation specs
On 2015-05-28 16:53, Simo Sorce wrote: We can't have 2 different keytabs with the same principal name. If we need privilege separation we'll have to work on integrating GSS-Proxy and give the keytab only to GSS-Proxy leaving it off the hands of both the framework, the proxy, and apache itself. I had a different principal like KDCPROXY/fqdn@realm in mind. Although to be honest I do not see why the proxy need access to the keytab at all, can we simply run it as a wsgi application under a different user and prevent it from accessing the apache keytab at all ? Yes, mod_wsgi is able to run a WSGI app as a different user: https://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess A different user needs another location for the ccache and perhaps additional SELinux rules. What do we need the keytab for ? Is it just in order to authenticate and read if the service is enabled ? Can we make that information available anonymously ? Yes, the information is not available for anon bind. It doesn't feel right to disclose the settings to the public. Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] KDC proxy implementation specs
On 2015-05-28 16:48, Nathaniel McCallum wrote: An apache module would also provide similar benefits. I'm not sure I necessarily want to stick with python here if we're optimizing for performance. Another option would be to add it to the KDC itself and proxy through Apache like we do for Tomcat. MIT might like that option. For that kind of network code Python is really fast enough. An event driven framework like asyncio or Twisted can handle lots of connections simultaneous. We aren't speaking about several GBit/sec where zero-copy is required. I'm more worried about Apache than Python. Apache is tuned for the needs of the webui, e.g. prefork MPM. Let's see how it works out in a production system. Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] KDC proxy implementation specs
On Thu, 2015-05-28 at 16:34 +0200, Christian Heimes wrote: Hello, thanks you for your input. The former thread has 58 messages in total. Since last Friday we have came to an agreement in most points. I like to some up our decisions and focus on some minor details. decisions - python-kdcproxy will be installed as a dependency of freeipa-server. There won't be a separate freeipa-server-kdcproxy package. That may or may not change in the future. The decision is out of scope for 4.2.0. [1] KDC proxy support will be enabled by default. The config files and LDAP settings will be created by ipa-server-install, ipa-server-upgrade and ipa-replica-install. The enabled/disabled switch will be stored per-replica in the cn=masters,cn=ipa,cn=etc tree. An API and CLI tool for management is postponed. [2] For now we settle for some doc examples that use the ipa-ldap-updater as suggested by Alex. [3] open for discussion --- Jan has suggested to ipaConfigString=kdcProxyEnabled in cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc instead of ipaConfigString=enabledService in cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc. It makes sense to me. After all MS-KKDCP is just another transport for the KDC. [4] There may be a security concern here if we aren't careful. I think I'm in favor of KDCPROXY since it is a different application. Martin Basti suggested a different keytab and principal for kdcproxy. [5] The keytab is only required for GSSAPI bind to lookup the state of the enabled/disabled switch. The current patch uses the same keytab as webgui. A new principal separates kdcproxy more cleanly and allows for fine-grained ACIs. It is also more future proof. It may also have auditing benefits now that we are beginning to think about the A in FreeIPA. In the future we may want to move kdcproxy from an Apache WSGI app to a separate service. A dedicated Twisted or asyncio daemon could handle more load. A separate keytab is easy to implement, too. I looked at the code in HTTPInstance.__create_http_keytab(). An apache module would also provide similar benefits. I'm not sure I necessarily want to stick with python here if we're optimizing for performance. Another option would be to add it to the KDC itself and proxy through Apache like we do for Tomcat. MIT might like that option. For the ACI I plan to add a new permission 'System: Read IPA Config String' and make the principal a direct memberOf of it. We don't have service roles yet. cn=roles,cn=accounts look like end user roles to me. The new ACI in cn=masters,cn=ipa,cn=etc will grant read, search and compare permission: (targetfilter = (objectClass=nsContainer))(targetattr = cn || objectClass || ipaConfigString)(version 3.0; acl Read IPA Config String; allow (read, search, compare) groupdn = ldap:///cn=System: Read IPA Config String,cn=permissions,cn=pbac,dc=ipa,dc=example;) I should be able to modify and test my patch in a matter of a couple of hours. Christian [1] http://www.redhat.com/archives/freeipa-devel/2015-May/msg00535.html [2] http://www.redhat.com/archives/freeipa-devel/2015-May/msg00555.html [3] http://www.redhat.com/archives/freeipa-devel/2015-May/msg00533.html [4] http://www.redhat.com/archives/freeipa-devel/2015-May/msg00543.html [5] http://www.redhat.com/archives/freeipa-devel/2015-May/msg00539.html -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] KDC proxy implementation specs
On Thu, 2015-05-28 at 17:07 +0200, Christian Heimes wrote: On 2015-05-28 16:48, Nathaniel McCallum wrote: An apache module would also provide similar benefits. I'm not sure I necessarily want to stick with python here if we're optimizing for performance. Another option would be to add it to the KDC itself and proxy through Apache like we do for Tomcat. MIT might like that option. For that kind of network code Python is really fast enough. An event driven framework like asyncio or Twisted can handle lots of connections simultaneous. We aren't speaking about several GBit/sec where zero -copy is required. I'm more worried about Apache than Python. Apache is tuned for the needs of the webui, e.g. prefork MPM. Let's see how it works out in a production system. Right. And the KDC could just parse the messages directly. I agree. Let's wait and see. Nathaniel -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] KDC proxy implementation specs
On Thu, 2015-05-28 at 17:00 +0200, Christian Heimes wrote: On 2015-05-28 16:53, Simo Sorce wrote: We can't have 2 different keytabs with the same principal name. If we need privilege separation we'll have to work on integrating GSS-Proxy and give the keytab only to GSS-Proxy leaving it off the hands of both the framework, the proxy, and apache itself. I had a different principal like KDCPROXY/fqdn@realm in mind. Although to be honest I do not see why the proxy need access to the keytab at all, can we simply run it as a wsgi application under a different user and prevent it from accessing the apache keytab at all ? Yes, mod_wsgi is able to run a WSGI app as a different user: https://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess A different user needs another location for the ccache and perhaps additional SELinux rules. If you are using the keytab only to acquire credentials to access ldap you could use a memory ccache and not have to deal with locations: KRB5CCNAME=MEMORY:kdcproxy_random_number What do we need the keytab for ? Is it just in order to authenticate and read if the service is enabled ? Can we make that information available anonymously ? Yes, the information is not available for anon bind. It doesn't feel right to disclose the settings to the public. Another option is to use ldapi and external auth, I forgot if we allow automatic binding for no-root users though. Rob, do you remember ? Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] KDC proxy implementation specs
On 2015-05-28 17:10, Simo Sorce wrote: On Thu, 2015-05-28 at 17:00 +0200, Christian Heimes wrote: On 2015-05-28 16:53, Simo Sorce wrote: We can't have 2 different keytabs with the same principal name. If we need privilege separation we'll have to work on integrating GSS-Proxy and give the keytab only to GSS-Proxy leaving it off the hands of both the framework, the proxy, and apache itself. I had a different principal like KDCPROXY/fqdn@realm in mind. Although to be honest I do not see why the proxy need access to the keytab at all, can we simply run it as a wsgi application under a different user and prevent it from accessing the apache keytab at all ? Yes, mod_wsgi is able to run a WSGI app as a different user: https://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess A different user needs another location for the ccache and perhaps additional SELinux rules. If you are using the keytab only to acquire credentials to access ldap you could use a memory ccache and not have to deal with locations: KRB5CCNAME=MEMORY:kdcproxy_random_number Oh nice, I wasn't aware about the MEMORY scheme. Is that supported on older versions of RHEL, too? What do we need the keytab for ? Is it just in order to authenticate and read if the service is enabled ? Can we make that information available anonymously ? Yes, the information is not available for anon bind. It doesn't feel right to disclose the settings to the public. Another option is to use ldapi and external auth, I forgot if we allow automatic binding for no-root users though. No, been there, tried it, failed. It works as root but not as Apache user or my test user. Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] KDC proxy implementation specs
Simo Sorce wrote: On Thu, 2015-05-28 at 17:00 +0200, Christian Heimes wrote: On 2015-05-28 16:53, Simo Sorce wrote: We can't have 2 different keytabs with the same principal name. If we need privilege separation we'll have to work on integrating GSS-Proxy and give the keytab only to GSS-Proxy leaving it off the hands of both the framework, the proxy, and apache itself. I had a different principal like KDCPROXY/fqdn@realm in mind. Although to be honest I do not see why the proxy need access to the keytab at all, can we simply run it as a wsgi application under a different user and prevent it from accessing the apache keytab at all ? Yes, mod_wsgi is able to run a WSGI app as a different user: https://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess A different user needs another location for the ccache and perhaps additional SELinux rules. If you are using the keytab only to acquire credentials to access ldap you could use a memory ccache and not have to deal with locations: KRB5CCNAME=MEMORY:kdcproxy_random_number What do we need the keytab for ? Is it just in order to authenticate and read if the service is enabled ? Can we make that information available anonymously ? Yes, the information is not available for anon bind. It doesn't feel right to disclose the settings to the public. Another option is to use ldapi and external auth, I forgot if we allow automatic binding for no-root users though. Rob, do you remember ? AFAIK we have no rules other than root - DM. rob -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] KDC proxy implementation specs
On Thu, 2015-05-28 at 17:13 +0200, Christian Heimes wrote: On 2015-05-28 17:10, Simo Sorce wrote: On Thu, 2015-05-28 at 17:00 +0200, Christian Heimes wrote: On 2015-05-28 16:53, Simo Sorce wrote: We can't have 2 different keytabs with the same principal name. If we need privilege separation we'll have to work on integrating GSS-Proxy and give the keytab only to GSS-Proxy leaving it off the hands of both the framework, the proxy, and apache itself. I had a different principal like KDCPROXY/fqdn@realm in mind. Although to be honest I do not see why the proxy need access to the keytab at all, can we simply run it as a wsgi application under a different user and prevent it from accessing the apache keytab at all ? Yes, mod_wsgi is able to run a WSGI app as a different user: https://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess A different user needs another location for the ccache and perhaps additional SELinux rules. If you are using the keytab only to acquire credentials to access ldap you could use a memory ccache and not have to deal with locations: KRB5CCNAME=MEMORY:kdcproxy_random_number Oh nice, I wasn't aware about the MEMORY scheme. Is that supported on older versions of RHEL, too? Yes, it has been there for a long while. What do we need the keytab for ? Is it just in order to authenticate and read if the service is enabled ? Can we make that information available anonymously ? Yes, the information is not available for anon bind. It doesn't feel right to disclose the settings to the public. Another option is to use ldapi and external auth, I forgot if we allow automatic binding for no-root users though. No, been there, tried it, failed. It works as root but not as Apache user or my test user. Maybe we can enable it in cn=config, need to check what's needed, but it may be worth, if all you need is to read a few entries. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
