[Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)?
Hello list, the thread named's LDAP connection hangs on freeipa-users list [1] opened question Why do we use Kerberos for named-DS connection? Named connects over LDAPI to local DS instance anyway. Maybe we can get rid of Kerberos for this particular connection and use autobind instead. It would make it more reliable and effective. As a side effect, named will be able to start even if KDC is down for some reason. It partially solves chicken-egg problem during IPA start-up. I wasn't around when it bind-dyndb-ldap was designed so I don't know historical reasons. [1] https://www.redhat.com/archives/freeipa-users/2014-June/msg00065.html -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)?
On Thu, Jun 19, 2014 at 09:43:06AM +0200, Petr Spacek wrote: Hello list, the thread named's LDAP connection hangs on freeipa-users list [1] opened question Why do we use Kerberos for named-DS connection? Named connects over LDAPI to local DS instance anyway. Maybe we can get rid of Kerberos for this particular connection and use autobind instead. It would make it more reliable and effective. As a side effect, named will be able to start even if KDC is down for some reason. It partially solves chicken-egg problem during IPA start-up. I wasn't around when it bind-dyndb-ldap was designed so I don't know historical reasons. I think there are two differences: # ldapexop -H 'ldapi://%2fvar%2frun%2fslapd-IPA20-DEVEL.socket' whoami SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn: cn=Directory Manager # ldapexop -H 'ldapi://%2fvar%2frun%2fslapd-IPA20-DEVEL.socket' whoami -Y GSSAPI SASL/GSSAPI authentication started SASL username: DNS/ipa20-devel.ipa20.devel@IPA20.DEVEL SASL SSF: 56 SASL data security layer installed. dn: krbprincipalname=dns/ipa20-devel.ipa20.devel@ipa20.devel,cn=services,cn=accounts,dc=ipa20,dc=devel With Kerberos you bind with a specific DN and all access control rule can be applied for the connection. Additionally you have an SSF level. I think most of our plugin which requires a secure connection check not only SSF but check if the connection is coming via the ldapi socket as well but there might some which miss this check. We use LDAPI+Kerberos in samba as well to access the IPA DS, but I agree that samba is not that important for IPA and there is no chicken-egg problem. bye, Sumit [1] https://www.redhat.com/archives/freeipa-users/2014-June/msg00065.html -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)?
On Thu, 19 Jun 2014, Petr Spacek wrote: Hello list, the thread named's LDAP connection hangs on freeipa-users list [1] opened question Why do we use Kerberos for named-DS connection? Named connects over LDAPI to local DS instance anyway. Maybe we can get rid of Kerberos for this particular connection and use autobind instead. It would make it more reliable and effective. As a side effect, named will be able to start even if KDC is down for some reason. It partially solves chicken-egg problem during IPA start-up. I wasn't around when it bind-dyndb-ldap was designed so I don't know historical reasons. My primary worry is the fact that any break in named/bind-dyndb-ldap could be then exploited to have access to all key material. In the case of GSSAPI you are confined to whatever ACIs allow for dns/ principal. Samba case goes further -- I specifically added GSSAPI bind to Samba code LDAP code to allow splitting DCs and file servers while being able to use the same ipasam module securely, in addition to the usual ACI limitations. For named what we could do is to have named+ldapi:// access mapped to specific DN uidNumber=named+gidNumbe=named,cn=peercred,cn=external,cn=auth achieving essentially the same thing, if we would use dn: cn=config nsslapd-ldapimaptoentries: on nsslapd-ldapiuidnumbertype: uidNumber nsslapd-ldapigidnumbertype: gidNumber nsslapd-ldapientrysearchbase: cn=accounts,$SUFFIX and dn: krbprincipalname=dns/$master@$REALM,cn=services,cn=accounts,$SUFFIX uidNumber: uid for named gidNumber: gid for named and then define ACIs equal to what we have for DNS service now. There is an issue of uid/gid being different on different platforms, though but it is doable. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)?
On 19.6.2014 11:02, Alexander Bokovoy wrote: On Thu, 19 Jun 2014, Petr Spacek wrote: the thread named's LDAP connection hangs on freeipa-users list [1] opened question Why do we use Kerberos for named-DS connection? Named connects over LDAPI to local DS instance anyway. Maybe we can get rid of Kerberos for this particular connection and use autobind instead. It would make it more reliable and effective. As a side effect, named will be able to start even if KDC is down for some reason. It partially solves chicken-egg problem during IPA start-up. I wasn't around when it bind-dyndb-ldap was designed so I don't know historical reasons. My primary worry is the fact that any break in named/bind-dyndb-ldap could be then exploited to have access to all key material. In the case of GSSAPI you are confined to whatever ACIs allow for dns/ principal. IMHO autobind maps uid+gid to a DN and normal ACIs apply after that so I don't see any difference from using SASL/GSSAPI/Kerberos. Samba case goes further -- I specifically added GSSAPI bind to Samba code LDAP code to allow splitting DCs and file servers while being able to use the same ipasam module securely, in addition to the usual ACI limitations. Named has only one function (i.e. DNS server with support for DNS updates). I don't think that there is meaningful separation. For named what we could do is to have named+ldapi:// access mapped to specific DN uidNumber=named+gidNumbe=named,cn=peercred,cn=external,cn=auth This is OpenLDAP-ism, right? achieving essentially the same thing, if we would use dn: cn=config nsslapd-ldapimaptoentries: on nsslapd-ldapiuidnumbertype: uidNumber nsslapd-ldapigidnumbertype: gidNumber nsslapd-ldapientrysearchbase: cn=accounts,$SUFFIX This is part of default IPA installation. and dn: krbprincipalname=dns/$master@$REALM,cn=services,cn=accounts,$SUFFIX This object already exists for every single DNS server, which is exactly the problem. Multiple servers are running under the same UID/GID pair on Fedora. uidNumber: uid for named gidNumber: gid for named and then define ACIs equal to what we have for DNS service now. ACIs are already in place and associated with the principals mentioned above. There is an issue of uid/gid being different on different platforms, though but it is doable. I can see the problem with UID/GID mapping to multiple different principals. We can't remove these principals because they are used on server side for DNS updates. Maybe we can create autobind mapping objects in some non-replicated part of the tree. That would solve the problem with different UID/GIDs on different platforms and also mapping UID/GID mapping to multiple principals because one replica would see only one mapping object for given UID/GID. It would be even better if DS could do something like: dn: uidNumber=uid+gidNumber=gid, cn=autobind, cn=config uidNumber: uid gidNumber: gid autobindDN: krbprincipalname=dns/$master@$REALM,cn=services,cn=accounts,$SUFFIX I.e. add one layer of indirection to autobind evaluation. That would allow us to have autobind object in non-replicated part of the tree and at the same time centralize ACIs under one DN (i.e. principal) in replicated part of the tree. I guess that it would require DS modification... -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)?
On Thu, 19 Jun 2014, Petr Spacek wrote:
On 19.6.2014 11:02, Alexander Bokovoy wrote:
On Thu, 19 Jun 2014, Petr Spacek wrote:
the thread named's LDAP connection hangs on freeipa-users list [1] opened
question Why do we use Kerberos for named-DS connection? Named connects
over LDAPI to local DS instance anyway.
Maybe we can get rid of Kerberos for this particular connection and use
autobind instead. It would make it more reliable and effective.
As a side effect, named will be able to start even if KDC is down for some
reason. It partially solves chicken-egg problem during IPA start-up.
I wasn't around when it bind-dyndb-ldap was designed so I don't know
historical reasons.
My primary worry is the fact that any break in named/bind-dyndb-ldap
could be then exploited to have access to all key material. In the case of
GSSAPI you are confined to whatever ACIs allow for dns/ principal.
IMHO autobind maps uid+gid to a DN and normal ACIs apply after that so
I don't see any difference from using SASL/GSSAPI/Kerberos.
My impression was that you wanted autobind to Directory Manager (root
autobind), this is what I don't want to support, for sure.
Samba case goes further -- I specifically added GSSAPI bind to Samba
code LDAP code to allow splitting DCs and file servers while being able
to use the same ipasam module securely, in addition to the usual
ACI limitations.
Named has only one function (i.e. DNS server with support for DNS
updates). I don't think that there is meaningful separation.
For named what we could do is to have named+ldapi:// access mapped to
specific DN uidNumber=named+gidNumbe=named,cn=peercred,cn=external,cn=auth
This is OpenLDAP-ism, right?
yes, this is what the client code reports. 389-ds server sees proper dn:
# ipa service-mod DNS/ipa-01.t.vda...@t.vda.li \
--addattr=objectclass=posixgroup --addattr=objectclass=posixaccount \
--setattr=cn=DNS/ipa-01.t.vda.li --setattr=uidNumber=25 \
--setattr=gidNumber=25 --setattr=HomeDirectory=/var/named \
--setattr=uid=named
---
Modified service DNS/ipa-01.t.vda...@t.vda.li
---
Principal: DNS/ipa-01.t.vda...@t.vda.li
Managed by: ipa-01.t.vda.li
# su -l named -s /bin/bash -c 'ldapsearch -Y EXTERNAL -H
ldapi://%2fvar%2frun%2fslapd-T-VDA-LI.socket cn=config '
SASL/EXTERNAL authentication started
SASL username: gidNumber=25+uidNumber=25,cn=peercred,cn=external,cn=auth
SASL SSF: 0
# extended LDIF
#
# LDAPv3
# base dc=t,dc=vda,dc=li (default) with scope subtree
# filter: cn=config
# requesting: ALL
#
# search result
search: 2
result: 0 Success
# numResponses: 1
and here is what we see in the logs:
[19/Jun/2014:14:04:24 +0300] conn=177 AUTOBIND
dn=krbprincipalname=dns/ipa-01.t.vda...@t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li
[19/Jun/2014:14:04:24 +0300] conn=177 op=0 BIND
dn=krbprincipalname=dns/ipa-01.t.vda...@t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li
method=sasl version=3 mech=EXTERNAL
[19/Jun/2014:14:04:24 +0300] conn=177 op=0 RESULT err=0 tag=97 nentries=0 etime=0
dn=krbprincipalname=dns/ipa-01.t.vda...@t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li
[19/Jun/2014:14:04:24 +0300] conn=177 op=1 SRCH base=dc=t,dc=vda,dc=li scope=2
filter=(cn=config) attrs=ALL
[19/Jun/2014:14:04:24 +0300] conn=177 op=1 RESULT err=0 tag=101 nentries=0
etime=0
[19/Jun/2014:14:04:24 +0300] conn=177 op=2 UNBIND
dn: krbprincipalname=dns/$master@$REALM,cn=services,cn=accounts,$SUFFIX
This object already exists for every single DNS server, which is
exactly the problem. Multiple servers are running under the same
UID/GID pair on Fedora.
No, it is not a problem because there are multiple objects, one per
server.
There is an issue of uid/gid being different on different platforms,
though but it is doable.
I can see the problem with UID/GID mapping to multiple different
principals. We can't remove these principals because they are used on
server side for DNS updates.
Maybe we can create autobind mapping objects in some non-replicated
part of the tree. That would solve the problem with different UID/GIDs
on different platforms and also mapping UID/GID mapping to multiple
principals because one replica would see only one mapping object for
given UID/GID.
No, I don't think we ever need to modify anything here apart from giving
posixgroup/posixaccount object classes to the DNS principal per server
and setting their properties.
As you can see above, it simply works. I actually tested it with named
too, by setting
diff -up /etc/named.conf.old /etc/named.conf
--- /etc/named.conf.old 2014-06-19 14:10:40.725934702 +0300
+++ /etc/named.conf 2014-06-19 14:10:58.432601624 +0300
@@ -45,7 +45,7 @@ dynamic-db ipa {
arg base cn=dns, dc=t,dc=vda,dc=li;
arg fake_mname ipa-01.t.vda.li.;
arg auth_method sasl;
- arg sasl_mech GSSAPI;
- arg sasl_user DNS/ipa-01.t.vda.li;
+ arg sasl_mech EXTERNAL;
+
Re: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)?
On 19.6.2014 13:13, Alexander Bokovoy wrote:
On Thu, 19 Jun 2014, Petr Spacek wrote:
On 19.6.2014 11:02, Alexander Bokovoy wrote:
On Thu, 19 Jun 2014, Petr Spacek wrote:
the thread named's LDAP connection hangs on freeipa-users list [1] opened
question Why do we use Kerberos for named-DS connection? Named connects
over LDAPI to local DS instance anyway.
Maybe we can get rid of Kerberos for this particular connection and use
autobind instead. It would make it more reliable and effective.
As a side effect, named will be able to start even if KDC is down for some
reason. It partially solves chicken-egg problem during IPA start-up.
I wasn't around when it bind-dyndb-ldap was designed so I don't know
historical reasons.
My primary worry is the fact that any break in named/bind-dyndb-ldap
could be then exploited to have access to all key material. In the case of
GSSAPI you are confined to whatever ACIs allow for dns/ principal.
IMHO autobind maps uid+gid to a DN and normal ACIs apply after that so I
don't see any difference from using SASL/GSSAPI/Kerberos.
My impression was that you wanted autobind to Directory Manager (root
autobind), this is what I don't want to support, for sure.
Samba case goes further -- I specifically added GSSAPI bind to Samba
code LDAP code to allow splitting DCs and file servers while being able
to use the same ipasam module securely, in addition to the usual
ACI limitations.
Named has only one function (i.e. DNS server with support for DNS updates).
I don't think that there is meaningful separation.
For named what we could do is to have named+ldapi:// access mapped to
specific DN uidNumber=named+gidNumbe=named,cn=peercred,cn=external,cn=auth
This is OpenLDAP-ism, right?
yes, this is what the client code reports. 389-ds server sees proper dn:
# ipa service-mod DNS/ipa-01.t.vda...@t.vda.li \
--addattr=objectclass=posixgroup --addattr=objectclass=posixaccount \
--setattr=cn=DNS/ipa-01.t.vda.li --setattr=uidNumber=25 \
--setattr=gidNumber=25 --setattr=HomeDirectory=/var/named \
--setattr=uid=named
---
Modified service DNS/ipa-01.t.vda...@t.vda.li
---
Principal: DNS/ipa-01.t.vda...@t.vda.li
Managed by: ipa-01.t.vda.li
# su -l named -s /bin/bash -c 'ldapsearch -Y EXTERNAL -H
ldapi://%2fvar%2frun%2fslapd-T-VDA-LI.socket cn=config '
SASL/EXTERNAL authentication started
SASL username: gidNumber=25+uidNumber=25,cn=peercred,cn=external,cn=auth
SASL SSF: 0
# extended LDIF
#
# LDAPv3
# base dc=t,dc=vda,dc=li (default) with scope subtree
# filter: cn=config
# requesting: ALL
#
# search result
search: 2
result: 0 Success
# numResponses: 1
and here is what we see in the logs:
[19/Jun/2014:14:04:24 +0300] conn=177 AUTOBIND
dn=krbprincipalname=dns/ipa-01.t.vda...@t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li
[19/Jun/2014:14:04:24 +0300] conn=177 op=0 BIND
dn=krbprincipalname=dns/ipa-01.t.vda...@t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li
method=sasl version=3 mech=EXTERNAL
[19/Jun/2014:14:04:24 +0300] conn=177 op=0 RESULT err=0 tag=97 nentries=0
etime=0
dn=krbprincipalname=dns/ipa-01.t.vda...@t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li
[19/Jun/2014:14:04:24 +0300] conn=177 op=1 SRCH base=dc=t,dc=vda,dc=li
scope=2 filter=(cn=config) attrs=ALL
[19/Jun/2014:14:04:24 +0300] conn=177 op=1 RESULT err=0 tag=101 nentries=0
etime=0
[19/Jun/2014:14:04:24 +0300] conn=177 op=2 UNBIND
dn: krbprincipalname=dns/$master@$REALM,cn=services,cn=accounts,$SUFFIX
This object already exists for every single DNS server, which is exactly the
problem. Multiple servers are running under the same UID/GID pair on Fedora.
No, it is not a problem because there are multiple objects, one per
server.
There is an issue of uid/gid being different on different platforms,
though but it is doable.
I can see the problem with UID/GID mapping to multiple different principals.
We can't remove these principals because they are used on server side for
DNS updates.
Maybe we can create autobind mapping objects in some non-replicated part of
the tree. That would solve the problem with different UID/GIDs on different
platforms and also mapping UID/GID mapping to multiple principals because
one replica would see only one mapping object for given UID/GID.
No, I don't think we ever need to modify anything here apart from giving
posixgroup/posixaccount object classes to the DNS principal per server
and setting their properties.
As you can see above, it simply works. I actually tested it with named
too, by setting
diff -up /etc/named.conf.old /etc/named.conf
--- /etc/named.conf.old2014-06-19 14:10:40.725934702 +0300
+++ /etc/named.conf2014-06-19 14:10:58.432601624 +0300
@@ -45,7 +45,7 @@ dynamic-db ipa {
arg base cn=dns, dc=t,dc=vda,dc=li;
arg fake_mname ipa-01.t.vda.li.;
arg auth_method sasl;
-arg sasl_mech GSSAPI;
-arg sasl_user DNS/ipa-01.t.vda.li;
+arg
Re: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)?
On Thu, 19 Jun 2014, Petr Spacek wrote:
On 19.6.2014 13:13, Alexander Bokovoy wrote:
On Thu, 19 Jun 2014, Petr Spacek wrote:
On 19.6.2014 11:02, Alexander Bokovoy wrote:
On Thu, 19 Jun 2014, Petr Spacek wrote:
the thread named's LDAP connection hangs on freeipa-users list [1] opened
question Why do we use Kerberos for named-DS connection? Named connects
over LDAPI to local DS instance anyway.
Maybe we can get rid of Kerberos for this particular connection and use
autobind instead. It would make it more reliable and effective.
As a side effect, named will be able to start even if KDC is down for some
reason. It partially solves chicken-egg problem during IPA start-up.
I wasn't around when it bind-dyndb-ldap was designed so I don't know
historical reasons.
My primary worry is the fact that any break in named/bind-dyndb-ldap
could be then exploited to have access to all key material. In the case of
GSSAPI you are confined to whatever ACIs allow for dns/ principal.
IMHO autobind maps uid+gid to a DN and normal ACIs apply after that so I
don't see any difference from using SASL/GSSAPI/Kerberos.
My impression was that you wanted autobind to Directory Manager (root
autobind), this is what I don't want to support, for sure.
Samba case goes further -- I specifically added GSSAPI bind to Samba
code LDAP code to allow splitting DCs and file servers while being able
to use the same ipasam module securely, in addition to the usual
ACI limitations.
Named has only one function (i.e. DNS server with support for DNS updates).
I don't think that there is meaningful separation.
For named what we could do is to have named+ldapi:// access mapped to
specific DN uidNumber=named+gidNumbe=named,cn=peercred,cn=external,cn=auth
This is OpenLDAP-ism, right?
yes, this is what the client code reports. 389-ds server sees proper dn:
# ipa service-mod DNS/ipa-01.t.vda...@t.vda.li \
--addattr=objectclass=posixgroup --addattr=objectclass=posixaccount \
--setattr=cn=DNS/ipa-01.t.vda.li --setattr=uidNumber=25 \
--setattr=gidNumber=25 --setattr=HomeDirectory=/var/named \
--setattr=uid=named
---
Modified service DNS/ipa-01.t.vda...@t.vda.li
---
Principal: DNS/ipa-01.t.vda...@t.vda.li
Managed by: ipa-01.t.vda.li
# su -l named -s /bin/bash -c 'ldapsearch -Y EXTERNAL -H
ldapi://%2fvar%2frun%2fslapd-T-VDA-LI.socket cn=config '
SASL/EXTERNAL authentication started
SASL username: gidNumber=25+uidNumber=25,cn=peercred,cn=external,cn=auth
SASL SSF: 0
# extended LDIF
#
# LDAPv3
# base dc=t,dc=vda,dc=li (default) with scope subtree
# filter: cn=config
# requesting: ALL
#
# search result
search: 2
result: 0 Success
# numResponses: 1
and here is what we see in the logs:
[19/Jun/2014:14:04:24 +0300] conn=177 AUTOBIND
dn=krbprincipalname=dns/ipa-01.t.vda...@t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li
[19/Jun/2014:14:04:24 +0300] conn=177 op=0 BIND
dn=krbprincipalname=dns/ipa-01.t.vda...@t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li
method=sasl version=3 mech=EXTERNAL
[19/Jun/2014:14:04:24 +0300] conn=177 op=0 RESULT err=0 tag=97 nentries=0
etime=0
dn=krbprincipalname=dns/ipa-01.t.vda...@t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li
[19/Jun/2014:14:04:24 +0300] conn=177 op=1 SRCH base=dc=t,dc=vda,dc=li
scope=2 filter=(cn=config) attrs=ALL
[19/Jun/2014:14:04:24 +0300] conn=177 op=1 RESULT err=0 tag=101 nentries=0
etime=0
[19/Jun/2014:14:04:24 +0300] conn=177 op=2 UNBIND
dn: krbprincipalname=dns/$master@$REALM,cn=services,cn=accounts,$SUFFIX
This object already exists for every single DNS server, which is exactly the
problem. Multiple servers are running under the same UID/GID pair on Fedora.
No, it is not a problem because there are multiple objects, one per
server.
There is an issue of uid/gid being different on different platforms,
though but it is doable.
I can see the problem with UID/GID mapping to multiple different principals.
We can't remove these principals because they are used on server side for
DNS updates.
Maybe we can create autobind mapping objects in some non-replicated part of
the tree. That would solve the problem with different UID/GIDs on different
platforms and also mapping UID/GID mapping to multiple principals because
one replica would see only one mapping object for given UID/GID.
No, I don't think we ever need to modify anything here apart from giving
posixgroup/posixaccount object classes to the DNS principal per server
and setting their properties.
As you can see above, it simply works. I actually tested it with named
too, by setting
diff -up /etc/named.conf.old /etc/named.conf
--- /etc/named.conf.old2014-06-19 14:10:40.725934702 +0300
+++ /etc/named.conf2014-06-19 14:10:58.432601624 +0300
@@ -45,7 +45,7 @@ dynamic-db ipa {
arg base cn=dns, dc=t,dc=vda,dc=li;
arg fake_mname ipa-01.t.vda.li.;
arg auth_method sasl;
-arg sasl_mech GSSAPI;
-arg sasl_user
Re: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)?
On Thu, 2014-06-19 at 14:13 +0300, Alexander Bokovoy wrote:
On Thu, 19 Jun 2014, Petr Spacek wrote:
On 19.6.2014 11:02, Alexander Bokovoy wrote:
On Thu, 19 Jun 2014, Petr Spacek wrote:
the thread named's LDAP connection hangs on freeipa-users list [1] opened
question Why do we use Kerberos for named-DS connection? Named connects
over LDAPI to local DS instance anyway.
Maybe we can get rid of Kerberos for this particular connection and use
autobind instead. It would make it more reliable and effective.
As a side effect, named will be able to start even if KDC is down for some
reason. It partially solves chicken-egg problem during IPA start-up.
I wasn't around when it bind-dyndb-ldap was designed so I don't know
historical reasons.
My primary worry is the fact that any break in named/bind-dyndb-ldap
could be then exploited to have access to all key material. In the case of
GSSAPI you are confined to whatever ACIs allow for dns/ principal.
IMHO autobind maps uid+gid to a DN and normal ACIs apply after that so
I don't see any difference from using SASL/GSSAPI/Kerberos.
My impression was that you wanted autobind to Directory Manager (root
autobind), this is what I don't want to support, for sure.
Samba case goes further -- I specifically added GSSAPI bind to Samba
code LDAP code to allow splitting DCs and file servers while being able
to use the same ipasam module securely, in addition to the usual
ACI limitations.
Named has only one function (i.e. DNS server with support for DNS
updates). I don't think that there is meaningful separation.
For named what we could do is to have named+ldapi:// access mapped to
specific DN
uidNumber=named+gidNumbe=named,cn=peercred,cn=external,cn=auth
This is OpenLDAP-ism, right?
yes, this is what the client code reports. 389-ds server sees proper dn:
# ipa service-mod DNS/ipa-01.t.vda...@t.vda.li \
--addattr=objectclass=posixgroup --addattr=objectclass=posixaccount \
--setattr=cn=DNS/ipa-01.t.vda.li --setattr=uidNumber=25 \
--setattr=gidNumber=25 --setattr=HomeDirectory=/var/named \
--setattr=uid=named
---
Modified service DNS/ipa-01.t.vda...@t.vda.li
---
Principal: DNS/ipa-01.t.vda...@t.vda.li
Managed by: ipa-01.t.vda.li
# su -l named -s /bin/bash -c 'ldapsearch -Y EXTERNAL -H
ldapi://%2fvar%2frun%2fslapd-T-VDA-LI.socket cn=config '
SASL/EXTERNAL authentication started
SASL username: gidNumber=25+uidNumber=25,cn=peercred,cn=external,cn=auth
SASL SSF: 0
# extended LDIF
#
# LDAPv3
# base dc=t,dc=vda,dc=li (default) with scope subtree
# filter: cn=config
# requesting: ALL
#
# search result
search: 2
result: 0 Success
# numResponses: 1
and here is what we see in the logs:
[19/Jun/2014:14:04:24 +0300] conn=177 AUTOBIND
dn=krbprincipalname=dns/ipa-01.t.vda...@t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li
[19/Jun/2014:14:04:24 +0300] conn=177 op=0 BIND
dn=krbprincipalname=dns/ipa-01.t.vda...@t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li
method=sasl version=3 mech=EXTERNAL
[19/Jun/2014:14:04:24 +0300] conn=177 op=0 RESULT err=0 tag=97 nentries=0
etime=0
dn=krbprincipalname=dns/ipa-01.t.vda...@t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li
[19/Jun/2014:14:04:24 +0300] conn=177 op=1 SRCH base=dc=t,dc=vda,dc=li
scope=2 filter=(cn=config) attrs=ALL
[19/Jun/2014:14:04:24 +0300] conn=177 op=1 RESULT err=0 tag=101 nentries=0
etime=0
[19/Jun/2014:14:04:24 +0300] conn=177 op=2 UNBIND
dn: krbprincipalname=dns/$master@$REALM,cn=services,cn=accounts,$SUFFIX
This object already exists for every single DNS server, which is
exactly the problem. Multiple servers are running under the same
UID/GID pair on Fedora.
No, it is not a problem because there are multiple objects, one per
server.
There is an issue of uid/gid being different on different platforms,
though but it is doable.
I can see the problem with UID/GID mapping to multiple different
principals. We can't remove these principals because they are used on
server side for DNS updates.
Maybe we can create autobind mapping objects in some non-replicated
part of the tree. That would solve the problem with different UID/GIDs
on different platforms and also mapping UID/GID mapping to multiple
principals because one replica would see only one mapping object for
given UID/GID.
No, I don't think we ever need to modify anything here apart from giving
posixgroup/posixaccount object classes to the DNS principal per server
and setting their properties.
As you can see above, it simply works. I actually tested it with named
too, by setting
diff -up /etc/named.conf.old /etc/named.conf
--- /etc/named.conf.old 2014-06-19 14:10:40.725934702 +0300
+++ /etc/named.conf 2014-06-19 14:10:58.432601624 +0300
@@ -45,7 +45,7 @@ dynamic-db ipa {
arg base cn=dns, dc=t,dc=vda,dc=li;
arg
Re: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)?
On Thu, 2014-06-19 at 09:43 +0200, Petr Spacek wrote: Hello list, the thread named's LDAP connection hangs on freeipa-users list [1] opened question Why do we use Kerberos for named-DS connection? Named connects over LDAPI to local DS instance anyway. Maybe we can get rid of Kerberos for this particular connection and use autobind instead. It would make it more reliable and effective. As a side effect, named will be able to start even if KDC is down for some reason. It partially solves chicken-egg problem during IPA start-up. I wasn't around when it bind-dyndb-ldap was designed so I don't know historical reasons. [1] https://www.redhat.com/archives/freeipa-users/2014-June/msg00065.html I would be in favor if we can make bind run as an unprivileged user instead of root, can we do that ? Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)?
On 19.6.2014 15:28, Simo Sorce wrote: On Thu, 2014-06-19 at 09:43 +0200, Petr Spacek wrote: Hello list, the thread named's LDAP connection hangs on freeipa-users list [1] opened question Why do we use Kerberos for named-DS connection? Named connects over LDAPI to local DS instance anyway. Maybe we can get rid of Kerberos for this particular connection and use autobind instead. It would make it more reliable and effective. As a side effect, named will be able to start even if KDC is down for some reason. It partially solves chicken-egg problem during IPA start-up. I wasn't around when it bind-dyndb-ldap was designed so I don't know historical reasons. [1] https://www.redhat.com/archives/freeipa-users/2014-June/msg00065.html I would be in favor if we can make bind run as an unprivileged user instead of root, can we do that ? We already do that :-) The user is called 'named'. -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)?
On Thu, 19 Jun 2014, Simo Sorce wrote:
On Thu, 2014-06-19 at 14:13 +0300, Alexander Bokovoy wrote:
On Thu, 19 Jun 2014, Petr Spacek wrote:
On 19.6.2014 11:02, Alexander Bokovoy wrote:
On Thu, 19 Jun 2014, Petr Spacek wrote:
the thread named's LDAP connection hangs on freeipa-users list [1] opened
question Why do we use Kerberos for named-DS connection? Named connects
over LDAPI to local DS instance anyway.
Maybe we can get rid of Kerberos for this particular connection and use
autobind instead. It would make it more reliable and effective.
As a side effect, named will be able to start even if KDC is down for some
reason. It partially solves chicken-egg problem during IPA start-up.
I wasn't around when it bind-dyndb-ldap was designed so I don't know
historical reasons.
My primary worry is the fact that any break in named/bind-dyndb-ldap
could be then exploited to have access to all key material. In the case of
GSSAPI you are confined to whatever ACIs allow for dns/ principal.
IMHO autobind maps uid+gid to a DN and normal ACIs apply after that so
I don't see any difference from using SASL/GSSAPI/Kerberos.
My impression was that you wanted autobind to Directory Manager (root
autobind), this is what I don't want to support, for sure.
Samba case goes further -- I specifically added GSSAPI bind to Samba
code LDAP code to allow splitting DCs and file servers while being able
to use the same ipasam module securely, in addition to the usual
ACI limitations.
Named has only one function (i.e. DNS server with support for DNS
updates). I don't think that there is meaningful separation.
For named what we could do is to have named+ldapi:// access mapped to
specific DN uidNumber=named+gidNumbe=named,cn=peercred,cn=external,cn=auth
This is OpenLDAP-ism, right?
yes, this is what the client code reports. 389-ds server sees proper dn:
# ipa service-mod DNS/ipa-01.t.vda...@t.vda.li \
--addattr=objectclass=posixgroup --addattr=objectclass=posixaccount \
--setattr=cn=DNS/ipa-01.t.vda.li --setattr=uidNumber=25 \
--setattr=gidNumber=25 --setattr=HomeDirectory=/var/named \
--setattr=uid=named
---
Modified service DNS/ipa-01.t.vda...@t.vda.li
---
Principal: DNS/ipa-01.t.vda...@t.vda.li
Managed by: ipa-01.t.vda.li
# su -l named -s /bin/bash -c 'ldapsearch -Y EXTERNAL -H
ldapi://%2fvar%2frun%2fslapd-T-VDA-LI.socket cn=config '
SASL/EXTERNAL authentication started
SASL username: gidNumber=25+uidNumber=25,cn=peercred,cn=external,cn=auth
SASL SSF: 0
# extended LDIF
#
# LDAPv3
# base dc=t,dc=vda,dc=li (default) with scope subtree
# filter: cn=config
# requesting: ALL
#
# search result
search: 2
result: 0 Success
# numResponses: 1
and here is what we see in the logs:
[19/Jun/2014:14:04:24 +0300] conn=177 AUTOBIND
dn=krbprincipalname=dns/ipa-01.t.vda...@t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li
[19/Jun/2014:14:04:24 +0300] conn=177 op=0 BIND
dn=krbprincipalname=dns/ipa-01.t.vda...@t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li
method=sasl version=3 mech=EXTERNAL
[19/Jun/2014:14:04:24 +0300] conn=177 op=0 RESULT err=0 tag=97 nentries=0 etime=0
dn=krbprincipalname=dns/ipa-01.t.vda...@t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li
[19/Jun/2014:14:04:24 +0300] conn=177 op=1 SRCH base=dc=t,dc=vda,dc=li scope=2
filter=(cn=config) attrs=ALL
[19/Jun/2014:14:04:24 +0300] conn=177 op=1 RESULT err=0 tag=101 nentries=0
etime=0
[19/Jun/2014:14:04:24 +0300] conn=177 op=2 UNBIND
dn: krbprincipalname=dns/$master@$REALM,cn=services,cn=accounts,$SUFFIX
This object already exists for every single DNS server, which is
exactly the problem. Multiple servers are running under the same
UID/GID pair on Fedora.
No, it is not a problem because there are multiple objects, one per
server.
There is an issue of uid/gid being different on different platforms,
though but it is doable.
I can see the problem with UID/GID mapping to multiple different
principals. We can't remove these principals because they are used on
server side for DNS updates.
Maybe we can create autobind mapping objects in some non-replicated
part of the tree. That would solve the problem with different UID/GIDs
on different platforms and also mapping UID/GID mapping to multiple
principals because one replica would see only one mapping object for
given UID/GID.
No, I don't think we ever need to modify anything here apart from giving
posixgroup/posixaccount object classes to the DNS principal per server
and setting their properties.
As you can see above, it simply works. I actually tested it with named
too, by setting
diff -up /etc/named.conf.old /etc/named.conf
--- /etc/named.conf.old 2014-06-19 14:10:40.725934702 +0300
+++ /etc/named.conf 2014-06-19 14:10:58.432601624 +0300
@@ -45,7 +45,7 @@ dynamic-db ipa {
arg base cn=dns, dc=t,dc=vda,dc=li;
arg fake_mname ipa-01.t.vda.li.;
arg auth_method sasl;
- arg sasl_mech GSSAPI;
-
Re: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)?
On 19.6.2014 15:36, Simo Sorce wrote:
On Thu, 2014-06-19 at 14:13 +0300, Alexander Bokovoy wrote:
On Thu, 19 Jun 2014, Petr Spacek wrote:
On 19.6.2014 11:02, Alexander Bokovoy wrote:
On Thu, 19 Jun 2014, Petr Spacek wrote:
the thread named's LDAP connection hangs on freeipa-users list [1] opened
question Why do we use Kerberos for named-DS connection? Named connects
over LDAPI to local DS instance anyway.
Maybe we can get rid of Kerberos for this particular connection and use
autobind instead. It would make it more reliable and effective.
As a side effect, named will be able to start even if KDC is down for some
reason. It partially solves chicken-egg problem during IPA start-up.
I wasn't around when it bind-dyndb-ldap was designed so I don't know
historical reasons.
My primary worry is the fact that any break in named/bind-dyndb-ldap
could be then exploited to have access to all key material. In the case of
GSSAPI you are confined to whatever ACIs allow for dns/ principal.
IMHO autobind maps uid+gid to a DN and normal ACIs apply after that so
I don't see any difference from using SASL/GSSAPI/Kerberos.
My impression was that you wanted autobind to Directory Manager (root
autobind), this is what I don't want to support, for sure.
Samba case goes further -- I specifically added GSSAPI bind to Samba
code LDAP code to allow splitting DCs and file servers while being able
to use the same ipasam module securely, in addition to the usual
ACI limitations.
Named has only one function (i.e. DNS server with support for DNS
updates). I don't think that there is meaningful separation.
For named what we could do is to have named+ldapi:// access mapped to
specific DN uidNumber=named+gidNumbe=named,cn=peercred,cn=external,cn=auth
This is OpenLDAP-ism, right?
yes, this is what the client code reports. 389-ds server sees proper dn:
# ipa service-mod DNS/ipa-01.t.vda...@t.vda.li \
--addattr=objectclass=posixgroup --addattr=objectclass=posixaccount \
--setattr=cn=DNS/ipa-01.t.vda.li --setattr=uidNumber=25 \
--setattr=gidNumber=25 --setattr=HomeDirectory=/var/named \
--setattr=uid=named
---
Modified service DNS/ipa-01.t.vda...@t.vda.li
---
Principal: DNS/ipa-01.t.vda...@t.vda.li
Managed by: ipa-01.t.vda.li
# su -l named -s /bin/bash -c 'ldapsearch -Y EXTERNAL -H
ldapi://%2fvar%2frun%2fslapd-T-VDA-LI.socket cn=config '
SASL/EXTERNAL authentication started
SASL username: gidNumber=25+uidNumber=25,cn=peercred,cn=external,cn=auth
SASL SSF: 0
# extended LDIF
#
# LDAPv3
# base dc=t,dc=vda,dc=li (default) with scope subtree
# filter: cn=config
# requesting: ALL
#
# search result
search: 2
result: 0 Success
# numResponses: 1
and here is what we see in the logs:
[19/Jun/2014:14:04:24 +0300] conn=177 AUTOBIND
dn=krbprincipalname=dns/ipa-01.t.vda...@t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li
[19/Jun/2014:14:04:24 +0300] conn=177 op=0 BIND
dn=krbprincipalname=dns/ipa-01.t.vda...@t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li
method=sasl version=3 mech=EXTERNAL
[19/Jun/2014:14:04:24 +0300] conn=177 op=0 RESULT err=0 tag=97 nentries=0 etime=0
dn=krbprincipalname=dns/ipa-01.t.vda...@t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li
[19/Jun/2014:14:04:24 +0300] conn=177 op=1 SRCH base=dc=t,dc=vda,dc=li scope=2
filter=(cn=config) attrs=ALL
[19/Jun/2014:14:04:24 +0300] conn=177 op=1 RESULT err=0 tag=101 nentries=0
etime=0
[19/Jun/2014:14:04:24 +0300] conn=177 op=2 UNBIND
dn: krbprincipalname=dns/$master@$REALM,cn=services,cn=accounts,$SUFFIX
This object already exists for every single DNS server, which is
exactly the problem. Multiple servers are running under the same
UID/GID pair on Fedora.
No, it is not a problem because there are multiple objects, one per
server.
There is an issue of uid/gid being different on different platforms,
though but it is doable.
I can see the problem with UID/GID mapping to multiple different
principals. We can't remove these principals because they are used on
server side for DNS updates.
Maybe we can create autobind mapping objects in some non-replicated
part of the tree. That would solve the problem with different UID/GIDs
on different platforms and also mapping UID/GID mapping to multiple
principals because one replica would see only one mapping object for
given UID/GID.
No, I don't think we ever need to modify anything here apart from giving
posixgroup/posixaccount object classes to the DNS principal per server
and setting their properties.
As you can see above, it simply works. I actually tested it with named
too, by setting
diff -up /etc/named.conf.old /etc/named.conf
--- /etc/named.conf.old 2014-06-19 14:10:40.725934702 +0300
+++ /etc/named.conf 2014-06-19 14:10:58.432601624 +0300
@@ -45,7 +45,7 @@ dynamic-db ipa {
arg base cn=dns, dc=t,dc=vda,dc=li;
arg fake_mname ipa-01.t.vda.li.;
arg auth_method sasl;
-
Re: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)?
On Thu, 19 Jun 2014, Simo Sorce wrote: On Thu, 2014-06-19 at 09:43 +0200, Petr Spacek wrote: Hello list, the thread named's LDAP connection hangs on freeipa-users list [1] opened question Why do we use Kerberos for named-DS connection? Named connects over LDAPI to local DS instance anyway. Maybe we can get rid of Kerberos for this particular connection and use autobind instead. It would make it more reliable and effective. As a side effect, named will be able to start even if KDC is down for some reason. It partially solves chicken-egg problem during IPA start-up. I wasn't around when it bind-dyndb-ldap was designed so I don't know historical reasons. [1] https://www.redhat.com/archives/freeipa-users/2014-June/msg00065.html I would be in favor if we can make bind run as an unprivileged user instead of root, can we do that ? It already runs as 'named' user, see my other mail with actual experiment results. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)?
On Thu, 2014-06-19 at 16:41 +0300, Alexander Bokovoy wrote: On Thu, 19 Jun 2014, Simo Sorce wrote: On Thu, 2014-06-19 at 14:13 +0300, Alexander Bokovoy wrote: On Thu, 19 Jun 2014, Petr Spacek wrote: On 19.6.2014 11:02, Alexander Bokovoy wrote: On Thu, 19 Jun 2014, Petr Spacek wrote: the thread named's LDAP connection hangs on freeipa-users list [1] opened question Why do we use Kerberos for named-DS connection? Named connects over LDAPI to local DS instance anyway. Maybe we can get rid of Kerberos for this particular connection and use autobind instead. It would make it more reliable and effective. As a side effect, named will be able to start even if KDC is down for some reason. It partially solves chicken-egg problem during IPA start-up. I wasn't around when it bind-dyndb-ldap was designed so I don't know historical reasons. My primary worry is the fact that any break in named/bind-dyndb-ldap could be then exploited to have access to all key material. In the case of GSSAPI you are confined to whatever ACIs allow for dns/ principal. IMHO autobind maps uid+gid to a DN and normal ACIs apply after that so I don't see any difference from using SASL/GSSAPI/Kerberos. My impression was that you wanted autobind to Directory Manager (root autobind), this is what I don't want to support, for sure. Samba case goes further -- I specifically added GSSAPI bind to Samba code LDAP code to allow splitting DCs and file servers while being able to use the same ipasam module securely, in addition to the usual ACI limitations. Named has only one function (i.e. DNS server with support for DNS updates). I don't think that there is meaningful separation. For named what we could do is to have named+ldapi:// access mapped to specific DN uidNumber=named+gidNumbe=named,cn=peercred,cn=external,cn=auth This is OpenLDAP-ism, right? yes, this is what the client code reports. 389-ds server sees proper dn: # ipa service-mod DNS/ipa-01.t.vda...@t.vda.li \ --addattr=objectclass=posixgroup --addattr=objectclass=posixaccount \ --setattr=cn=DNS/ipa-01.t.vda.li --setattr=uidNumber=25 \ --setattr=gidNumber=25 --setattr=HomeDirectory=/var/named \ --setattr=uid=named --- Modified service DNS/ipa-01.t.vda...@t.vda.li --- Principal: DNS/ipa-01.t.vda...@t.vda.li Managed by: ipa-01.t.vda.li # su -l named -s /bin/bash -c 'ldapsearch -Y EXTERNAL -H ldapi://%2fvar%2frun%2fslapd-T-VDA-LI.socket cn=config ' SASL/EXTERNAL authentication started SASL username: gidNumber=25+uidNumber=25,cn=peercred,cn=external,cn=auth SASL SSF: 0 # extended LDIF # # LDAPv3 # base dc=t,dc=vda,dc=li (default) with scope subtree # filter: cn=config # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 and here is what we see in the logs: [19/Jun/2014:14:04:24 +0300] conn=177 AUTOBIND dn=krbprincipalname=dns/ipa-01.t.vda...@t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li [19/Jun/2014:14:04:24 +0300] conn=177 op=0 BIND dn=krbprincipalname=dns/ipa-01.t.vda...@t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li method=sasl version=3 mech=EXTERNAL [19/Jun/2014:14:04:24 +0300] conn=177 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn=krbprincipalname=dns/ipa-01.t.vda...@t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li [19/Jun/2014:14:04:24 +0300] conn=177 op=1 SRCH base=dc=t,dc=vda,dc=li scope=2 filter=(cn=config) attrs=ALL [19/Jun/2014:14:04:24 +0300] conn=177 op=1 RESULT err=0 tag=101 nentries=0 etime=0 [19/Jun/2014:14:04:24 +0300] conn=177 op=2 UNBIND dn: krbprincipalname=dns/$master@$REALM,cn=services,cn=accounts,$SUFFIX This object already exists for every single DNS server, which is exactly the problem. Multiple servers are running under the same UID/GID pair on Fedora. No, it is not a problem because there are multiple objects, one per server. There is an issue of uid/gid being different on different platforms, though but it is doable. I can see the problem with UID/GID mapping to multiple different principals. We can't remove these principals because they are used on server side for DNS updates. Maybe we can create autobind mapping objects in some non-replicated part of the tree. That would solve the problem with different UID/GIDs on different platforms and also mapping UID/GID mapping to multiple principals because one replica would see only one mapping object for given UID/GID. No, I don't think we ever need to modify anything here apart from giving posixgroup/posixaccount object classes to the DNS principal per server and setting their properties. As you can see above, it simply works. I actually tested it with named too, by setting diff -up /etc/named.conf.old /etc/named.conf ---
Re: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)?
On Thu, 2014-06-19 at 15:41 +0200, Petr Spacek wrote: On 19.6.2014 15:36, Simo Sorce wrote: On Thu, 2014-06-19 at 14:13 +0300, Alexander Bokovoy wrote: On Thu, 19 Jun 2014, Petr Spacek wrote: On 19.6.2014 11:02, Alexander Bokovoy wrote: On Thu, 19 Jun 2014, Petr Spacek wrote: the thread named's LDAP connection hangs on freeipa-users list [1] opened question Why do we use Kerberos for named-DS connection? Named connects over LDAPI to local DS instance anyway. Maybe we can get rid of Kerberos for this particular connection and use autobind instead. It would make it more reliable and effective. As a side effect, named will be able to start even if KDC is down for some reason. It partially solves chicken-egg problem during IPA start-up. I wasn't around when it bind-dyndb-ldap was designed so I don't know historical reasons. My primary worry is the fact that any break in named/bind-dyndb-ldap could be then exploited to have access to all key material. In the case of GSSAPI you are confined to whatever ACIs allow for dns/ principal. IMHO autobind maps uid+gid to a DN and normal ACIs apply after that so I don't see any difference from using SASL/GSSAPI/Kerberos. My impression was that you wanted autobind to Directory Manager (root autobind), this is what I don't want to support, for sure. Samba case goes further -- I specifically added GSSAPI bind to Samba code LDAP code to allow splitting DCs and file servers while being able to use the same ipasam module securely, in addition to the usual ACI limitations. Named has only one function (i.e. DNS server with support for DNS updates). I don't think that there is meaningful separation. For named what we could do is to have named+ldapi:// access mapped to specific DN uidNumber=named+gidNumbe=named,cn=peercred,cn=external,cn=auth This is OpenLDAP-ism, right? yes, this is what the client code reports. 389-ds server sees proper dn: # ipa service-mod DNS/ipa-01.t.vda...@t.vda.li \ --addattr=objectclass=posixgroup --addattr=objectclass=posixaccount \ --setattr=cn=DNS/ipa-01.t.vda.li --setattr=uidNumber=25 \ --setattr=gidNumber=25 --setattr=HomeDirectory=/var/named \ --setattr=uid=named --- Modified service DNS/ipa-01.t.vda...@t.vda.li --- Principal: DNS/ipa-01.t.vda...@t.vda.li Managed by: ipa-01.t.vda.li # su -l named -s /bin/bash -c 'ldapsearch -Y EXTERNAL -H ldapi://%2fvar%2frun%2fslapd-T-VDA-LI.socket cn=config ' SASL/EXTERNAL authentication started SASL username: gidNumber=25+uidNumber=25,cn=peercred,cn=external,cn=auth SASL SSF: 0 # extended LDIF # # LDAPv3 # base dc=t,dc=vda,dc=li (default) with scope subtree # filter: cn=config # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 and here is what we see in the logs: [19/Jun/2014:14:04:24 +0300] conn=177 AUTOBIND dn=krbprincipalname=dns/ipa-01.t.vda...@t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li [19/Jun/2014:14:04:24 +0300] conn=177 op=0 BIND dn=krbprincipalname=dns/ipa-01.t.vda...@t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li method=sasl version=3 mech=EXTERNAL [19/Jun/2014:14:04:24 +0300] conn=177 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn=krbprincipalname=dns/ipa-01.t.vda...@t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li [19/Jun/2014:14:04:24 +0300] conn=177 op=1 SRCH base=dc=t,dc=vda,dc=li scope=2 filter=(cn=config) attrs=ALL [19/Jun/2014:14:04:24 +0300] conn=177 op=1 RESULT err=0 tag=101 nentries=0 etime=0 [19/Jun/2014:14:04:24 +0300] conn=177 op=2 UNBIND dn: krbprincipalname=dns/$master@$REALM,cn=services,cn=accounts,$SUFFIX This object already exists for every single DNS server, which is exactly the problem. Multiple servers are running under the same UID/GID pair on Fedora. No, it is not a problem because there are multiple objects, one per server. There is an issue of uid/gid being different on different platforms, though but it is doable. I can see the problem with UID/GID mapping to multiple different principals. We can't remove these principals because they are used on server side for DNS updates. Maybe we can create autobind mapping objects in some non-replicated part of the tree. That would solve the problem with different UID/GIDs on different platforms and also mapping UID/GID mapping to multiple principals because one replica would see only one mapping object for given UID/GID. No, I don't think we ever need to modify anything here apart from giving posixgroup/posixaccount object classes to the DNS principal per server and setting their properties. As you can see above, it simply works. I actually tested it with named too, by setting diff -up /etc/named.conf.old /etc/named.conf --- /etc/named.conf.old
Re: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)?
On 19.6.2014 16:02, Simo Sorce wrote:
On Thu, 2014-06-19 at 16:41 +0300, Alexander Bokovoy wrote:
On Thu, 19 Jun 2014, Simo Sorce wrote:
On Thu, 2014-06-19 at 14:13 +0300, Alexander Bokovoy wrote:
On Thu, 19 Jun 2014, Petr Spacek wrote:
On 19.6.2014 11:02, Alexander Bokovoy wrote:
On Thu, 19 Jun 2014, Petr Spacek wrote:
the thread named's LDAP connection hangs on freeipa-users list [1] opened
question Why do we use Kerberos for named-DS connection? Named connects
over LDAPI to local DS instance anyway.
Maybe we can get rid of Kerberos for this particular connection and use
autobind instead. It would make it more reliable and effective.
As a side effect, named will be able to start even if KDC is down for some
reason. It partially solves chicken-egg problem during IPA start-up.
I wasn't around when it bind-dyndb-ldap was designed so I don't know
historical reasons.
My primary worry is the fact that any break in named/bind-dyndb-ldap
could be then exploited to have access to all key material. In the case of
GSSAPI you are confined to whatever ACIs allow for dns/ principal.
IMHO autobind maps uid+gid to a DN and normal ACIs apply after that so
I don't see any difference from using SASL/GSSAPI/Kerberos.
My impression was that you wanted autobind to Directory Manager (root
autobind), this is what I don't want to support, for sure.
Samba case goes further -- I specifically added GSSAPI bind to Samba
code LDAP code to allow splitting DCs and file servers while being able
to use the same ipasam module securely, in addition to the usual
ACI limitations.
Named has only one function (i.e. DNS server with support for DNS
updates). I don't think that there is meaningful separation.
For named what we could do is to have named+ldapi:// access mapped to
specific DN uidNumber=named+gidNumbe=named,cn=peercred,cn=external,cn=auth
This is OpenLDAP-ism, right?
yes, this is what the client code reports. 389-ds server sees proper dn:
# ipa service-mod DNS/ipa-01.t.vda...@t.vda.li \
--addattr=objectclass=posixgroup --addattr=objectclass=posixaccount \
--setattr=cn=DNS/ipa-01.t.vda.li --setattr=uidNumber=25 \
--setattr=gidNumber=25 --setattr=HomeDirectory=/var/named \
--setattr=uid=named
---
Modified service DNS/ipa-01.t.vda...@t.vda.li
---
Principal: DNS/ipa-01.t.vda...@t.vda.li
Managed by: ipa-01.t.vda.li
# su -l named -s /bin/bash -c 'ldapsearch -Y EXTERNAL -H
ldapi://%2fvar%2frun%2fslapd-T-VDA-LI.socket cn=config '
SASL/EXTERNAL authentication started
SASL username: gidNumber=25+uidNumber=25,cn=peercred,cn=external,cn=auth
SASL SSF: 0
# extended LDIF
#
# LDAPv3
# base dc=t,dc=vda,dc=li (default) with scope subtree
# filter: cn=config
# requesting: ALL
#
# search result
search: 2
result: 0 Success
# numResponses: 1
and here is what we see in the logs:
[19/Jun/2014:14:04:24 +0300] conn=177 AUTOBIND
dn=krbprincipalname=dns/ipa-01.t.vda...@t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li
[19/Jun/2014:14:04:24 +0300] conn=177 op=0 BIND
dn=krbprincipalname=dns/ipa-01.t.vda...@t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li
method=sasl version=3 mech=EXTERNAL
[19/Jun/2014:14:04:24 +0300] conn=177 op=0 RESULT err=0 tag=97 nentries=0 etime=0
dn=krbprincipalname=dns/ipa-01.t.vda...@t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li
[19/Jun/2014:14:04:24 +0300] conn=177 op=1 SRCH base=dc=t,dc=vda,dc=li scope=2
filter=(cn=config) attrs=ALL
[19/Jun/2014:14:04:24 +0300] conn=177 op=1 RESULT err=0 tag=101 nentries=0
etime=0
[19/Jun/2014:14:04:24 +0300] conn=177 op=2 UNBIND
dn: krbprincipalname=dns/$master@$REALM,cn=services,cn=accounts,$SUFFIX
This object already exists for every single DNS server, which is
exactly the problem. Multiple servers are running under the same
UID/GID pair on Fedora.
No, it is not a problem because there are multiple objects, one per
server.
There is an issue of uid/gid being different on different platforms,
though but it is doable.
I can see the problem with UID/GID mapping to multiple different
principals. We can't remove these principals because they are used on
server side for DNS updates.
Maybe we can create autobind mapping objects in some non-replicated
part of the tree. That would solve the problem with different UID/GIDs
on different platforms and also mapping UID/GID mapping to multiple
principals because one replica would see only one mapping object for
given UID/GID.
No, I don't think we ever need to modify anything here apart from giving
posixgroup/posixaccount object classes to the DNS principal per server
and setting their properties.
As you can see above, it simply works. I actually tested it with named
too, by setting
diff -up /etc/named.conf.old /etc/named.conf
--- /etc/named.conf.old 2014-06-19 14:10:40.725934702 +0300
+++ /etc/named.conf 2014-06-19 14:10:58.432601624 +0300
@@ -45,7 +45,7 @@ dynamic-db ipa {
arg base
Re: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)?
On Thu, 19 Jun 2014, Simo Sorce wrote: and named successfully started, with 389-ds showing autobind to the same krprincipalname=dns/... in the logs. why do we need to associate bind to dns/whatever ?? Because we already have ACIs given to dns/hostname to handle DNS entries. Which are easy to change on upgrade. we can have a sysaccount called named, like we did for kerberos before we had the ipa-kdb driver. A modification of DNS service with 'ipa service-mod' is all what we need for single node case, I tried it. I do not like it at all, plus each server has a different object and they would all be duplicates. I prefer very much a single, passwordless special user in sysconfig, added to the same group that control access for the DNS tree. autobind needs uidNumber=uid+gidNumber=gid search to resolve to a single entry. Given that replicas might be running on machines where 'named' user could deviate (think Fedora, RHEL, and Debian), there will still be multiple 'named' sysaccounts and the whole story will break. I don't see how this helps compared to having DNS/hostname principal object extended to cover uidNumber/gidNumber. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)?
On Thu, 2014-06-19 at 16:05 +0200, Petr Spacek wrote: On 19.6.2014 16:02, Simo Sorce wrote: On Thu, 2014-06-19 at 16:41 +0300, Alexander Bokovoy wrote: On Thu, 19 Jun 2014, Simo Sorce wrote: On Thu, 2014-06-19 at 14:13 +0300, Alexander Bokovoy wrote: On Thu, 19 Jun 2014, Petr Spacek wrote: On 19.6.2014 11:02, Alexander Bokovoy wrote: On Thu, 19 Jun 2014, Petr Spacek wrote: the thread named's LDAP connection hangs on freeipa-users list [1] opened question Why do we use Kerberos for named-DS connection? Named connects over LDAPI to local DS instance anyway. Maybe we can get rid of Kerberos for this particular connection and use autobind instead. It would make it more reliable and effective. As a side effect, named will be able to start even if KDC is down for some reason. It partially solves chicken-egg problem during IPA start-up. I wasn't around when it bind-dyndb-ldap was designed so I don't know historical reasons. My primary worry is the fact that any break in named/bind-dyndb-ldap could be then exploited to have access to all key material. In the case of GSSAPI you are confined to whatever ACIs allow for dns/ principal. IMHO autobind maps uid+gid to a DN and normal ACIs apply after that so I don't see any difference from using SASL/GSSAPI/Kerberos. My impression was that you wanted autobind to Directory Manager (root autobind), this is what I don't want to support, for sure. Samba case goes further -- I specifically added GSSAPI bind to Samba code LDAP code to allow splitting DCs and file servers while being able to use the same ipasam module securely, in addition to the usual ACI limitations. Named has only one function (i.e. DNS server with support for DNS updates). I don't think that there is meaningful separation. For named what we could do is to have named+ldapi:// access mapped to specific DN uidNumber=named+gidNumbe=named,cn=peercred,cn=external,cn=auth This is OpenLDAP-ism, right? yes, this is what the client code reports. 389-ds server sees proper dn: # ipa service-mod DNS/ipa-01.t.vda...@t.vda.li \ --addattr=objectclass=posixgroup --addattr=objectclass=posixaccount \ --setattr=cn=DNS/ipa-01.t.vda.li --setattr=uidNumber=25 \ --setattr=gidNumber=25 --setattr=HomeDirectory=/var/named \ --setattr=uid=named --- Modified service DNS/ipa-01.t.vda...@t.vda.li --- Principal: DNS/ipa-01.t.vda...@t.vda.li Managed by: ipa-01.t.vda.li # su -l named -s /bin/bash -c 'ldapsearch -Y EXTERNAL -H ldapi://%2fvar%2frun%2fslapd-T-VDA-LI.socket cn=config ' SASL/EXTERNAL authentication started SASL username: gidNumber=25+uidNumber=25,cn=peercred,cn=external,cn=auth SASL SSF: 0 # extended LDIF # # LDAPv3 # base dc=t,dc=vda,dc=li (default) with scope subtree # filter: cn=config # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 and here is what we see in the logs: [19/Jun/2014:14:04:24 +0300] conn=177 AUTOBIND dn=krbprincipalname=dns/ipa-01.t.vda...@t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li [19/Jun/2014:14:04:24 +0300] conn=177 op=0 BIND dn=krbprincipalname=dns/ipa-01.t.vda...@t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li method=sasl version=3 mech=EXTERNAL [19/Jun/2014:14:04:24 +0300] conn=177 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn=krbprincipalname=dns/ipa-01.t.vda...@t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li [19/Jun/2014:14:04:24 +0300] conn=177 op=1 SRCH base=dc=t,dc=vda,dc=li scope=2 filter=(cn=config) attrs=ALL [19/Jun/2014:14:04:24 +0300] conn=177 op=1 RESULT err=0 tag=101 nentries=0 etime=0 [19/Jun/2014:14:04:24 +0300] conn=177 op=2 UNBIND dn: krbprincipalname=dns/$master@$REALM,cn=services,cn=accounts,$SUFFIX This object already exists for every single DNS server, which is exactly the problem. Multiple servers are running under the same UID/GID pair on Fedora. No, it is not a problem because there are multiple objects, one per server. There is an issue of uid/gid being different on different platforms, though but it is doable. I can see the problem with UID/GID mapping to multiple different principals. We can't remove these principals because they are used on server side for DNS updates. Maybe we can create autobind mapping objects in some non-replicated part of the tree. That would solve the problem with different UID/GIDs on different platforms and also mapping UID/GID mapping to multiple principals because one replica would see only one mapping object for given UID/GID. No, I don't think we ever need to modify anything here apart from giving posixgroup/posixaccount object classes to the DNS principal per server and setting their properties. As you can see above, it simply works. I actually tested
Re: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)?
On Thu, 2014-06-19 at 17:10 +0300, Alexander Bokovoy wrote: On Thu, 19 Jun 2014, Simo Sorce wrote: and named successfully started, with 389-ds showing autobind to the same krprincipalname=dns/... in the logs. why do we need to associate bind to dns/whatever ?? Because we already have ACIs given to dns/hostname to handle DNS entries. Which are easy to change on upgrade. we can have a sysaccount called named, like we did for kerberos before we had the ipa-kdb driver. A modification of DNS service with 'ipa service-mod' is all what we need for single node case, I tried it. I do not like it at all, plus each server has a different object and they would all be duplicates. I prefer very much a single, passwordless special user in sysconfig, added to the same group that control access for the DNS tree. autobind needs uidNumber=uid+gidNumber=gid search to resolve to a single entry. Given that replicas might be running on machines where 'named' user could deviate (think Fedora, RHEL, and Debian), there will still be multiple 'named' sysaccounts and the whole story will break. I don't see how this helps compared to having DNS/hostname principal object extended to cover uidNumber/gidNumber. This is not really a huge issue. We need to allow access to the DNS tree to a group, so all we need is for install/upgrade script to check what is the named user on the system and create a corresponding system account. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)?
On Thu, 19 Jun 2014, Simo Sorce wrote: On Thu, 2014-06-19 at 17:10 +0300, Alexander Bokovoy wrote: On Thu, 19 Jun 2014, Simo Sorce wrote: and named successfully started, with 389-ds showing autobind to the same krprincipalname=dns/... in the logs. why do we need to associate bind to dns/whatever ?? Because we already have ACIs given to dns/hostname to handle DNS entries. Which are easy to change on upgrade. we can have a sysaccount called named, like we did for kerberos before we had the ipa-kdb driver. A modification of DNS service with 'ipa service-mod' is all what we need for single node case, I tried it. I do not like it at all, plus each server has a different object and they would all be duplicates. I prefer very much a single, passwordless special user in sysconfig, added to the same group that control access for the DNS tree. autobind needs uidNumber=uid+gidNumber=gid search to resolve to a single entry. Given that replicas might be running on machines where 'named' user could deviate (think Fedora, RHEL, and Debian), there will still be multiple 'named' sysaccounts and the whole story will break. I don't see how this helps compared to having DNS/hostname principal object extended to cover uidNumber/gidNumber. This is not really a huge issue. We need to allow access to the DNS tree to a group, so all we need is for install/upgrade script to check what is the named user on the system and create a corresponding system account. So, now we'll have to manage multiple named accounts named what, 'named1', 'named2', ... ? How to manage them? One solution could be to have multi-value uidNumber/gidNumber attributes... -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)?
On Thu, 2014-06-19 at 17:24 +0300, Alexander Bokovoy wrote: On Thu, 19 Jun 2014, Simo Sorce wrote: On Thu, 2014-06-19 at 17:10 +0300, Alexander Bokovoy wrote: On Thu, 19 Jun 2014, Simo Sorce wrote: and named successfully started, with 389-ds showing autobind to the same krprincipalname=dns/... in the logs. why do we need to associate bind to dns/whatever ?? Because we already have ACIs given to dns/hostname to handle DNS entries. Which are easy to change on upgrade. we can have a sysaccount called named, like we did for kerberos before we had the ipa-kdb driver. A modification of DNS service with 'ipa service-mod' is all what we need for single node case, I tried it. I do not like it at all, plus each server has a different object and they would all be duplicates. I prefer very much a single, passwordless special user in sysconfig, added to the same group that control access for the DNS tree. autobind needs uidNumber=uid+gidNumber=gid search to resolve to a single entry. Given that replicas might be running on machines where 'named' user could deviate (think Fedora, RHEL, and Debian), there will still be multiple 'named' sysaccounts and the whole story will break. I don't see how this helps compared to having DNS/hostname principal object extended to cover uidNumber/gidNumber. This is not really a huge issue. We need to allow access to the DNS tree to a group, so all we need is for install/upgrade script to check what is the named user on the system and create a corresponding system account. So, now we'll have to manage multiple named accounts named what, 'named1', 'named2', ... ? How to manage them? what is there to manage ? One solution could be to have multi-value uidNumber/gidNumber attributes... nope, you just need to create a new object only if one does not exist with the same uidNumber, and add it to the group we use for ACIs on DNS. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)?
On Thu, 19 Jun 2014, Simo Sorce wrote: On Thu, 2014-06-19 at 17:24 +0300, Alexander Bokovoy wrote: On Thu, 19 Jun 2014, Simo Sorce wrote: On Thu, 2014-06-19 at 17:10 +0300, Alexander Bokovoy wrote: On Thu, 19 Jun 2014, Simo Sorce wrote: and named successfully started, with 389-ds showing autobind to the same krprincipalname=dns/... in the logs. why do we need to associate bind to dns/whatever ?? Because we already have ACIs given to dns/hostname to handle DNS entries. Which are easy to change on upgrade. we can have a sysaccount called named, like we did for kerberos before we had the ipa-kdb driver. A modification of DNS service with 'ipa service-mod' is all what we need for single node case, I tried it. I do not like it at all, plus each server has a different object and they would all be duplicates. I prefer very much a single, passwordless special user in sysconfig, added to the same group that control access for the DNS tree. autobind needs uidNumber=uid+gidNumber=gid search to resolve to a single entry. Given that replicas might be running on machines where 'named' user could deviate (think Fedora, RHEL, and Debian), there will still be multiple 'named' sysaccounts and the whole story will break. I don't see how this helps compared to having DNS/hostname principal object extended to cover uidNumber/gidNumber. This is not really a huge issue. We need to allow access to the DNS tree to a group, so all we need is for install/upgrade script to check what is the named user on the system and create a corresponding system account. So, now we'll have to manage multiple named accounts named what, 'named1', 'named2', ... ? How to manage them? what is there to manage ? One solution could be to have multi-value uidNumber/gidNumber attributes... nope, you just need to create a new object only if one does not exist with the same uidNumber, and add it to the group we use for ACIs on DNS. I assume the account like that shouldn't have any password at all, to prevent its use over LDAP instead of LDAPI. I'm still a bit uncomfortable with it because if this trend goes, we'll be making such accounts for other services as well. Given that we have no means to manage sysaccounts from IPA right now, their life cycle is a bit weird. I may need to revive my sysaccounts module... -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)?
On Thu, 2014-06-19 at 17:33 +0300, Alexander Bokovoy wrote: On Thu, 19 Jun 2014, Simo Sorce wrote: On Thu, 2014-06-19 at 17:24 +0300, Alexander Bokovoy wrote: On Thu, 19 Jun 2014, Simo Sorce wrote: On Thu, 2014-06-19 at 17:10 +0300, Alexander Bokovoy wrote: On Thu, 19 Jun 2014, Simo Sorce wrote: and named successfully started, with 389-ds showing autobind to the same krprincipalname=dns/... in the logs. why do we need to associate bind to dns/whatever ?? Because we already have ACIs given to dns/hostname to handle DNS entries. Which are easy to change on upgrade. we can have a sysaccount called named, like we did for kerberos before we had the ipa-kdb driver. A modification of DNS service with 'ipa service-mod' is all what we need for single node case, I tried it. I do not like it at all, plus each server has a different object and they would all be duplicates. I prefer very much a single, passwordless special user in sysconfig, added to the same group that control access for the DNS tree. autobind needs uidNumber=uid+gidNumber=gid search to resolve to a single entry. Given that replicas might be running on machines where 'named' user could deviate (think Fedora, RHEL, and Debian), there will still be multiple 'named' sysaccounts and the whole story will break. I don't see how this helps compared to having DNS/hostname principal object extended to cover uidNumber/gidNumber. This is not really a huge issue. We need to allow access to the DNS tree to a group, so all we need is for install/upgrade script to check what is the named user on the system and create a corresponding system account. So, now we'll have to manage multiple named accounts named what, 'named1', 'named2', ... ? How to manage them? what is there to manage ? One solution could be to have multi-value uidNumber/gidNumber attributes... nope, you just need to create a new object only if one does not exist with the same uidNumber, and add it to the group we use for ACIs on DNS. I assume the account like that shouldn't have any password at all, to prevent its use over LDAP instead of LDAPI. Yep. I'm still a bit uncomfortable with it because if this trend goes, we'll be making such accounts for other services as well. Given that we have no means to manage sysaccounts from IPA right now, their life cycle is a bit weird. I know. I may need to revive my sysaccounts module... There is one more issue though, and this one really concerns me. If you need to put there multiple accounts because different servers have different local accounts, then you open up access to unrelated services. Because all these uids are shared on all systems. I think this kills my own proposal of sticking these entries in cn=sysaccounts. However we could have something in cn=config maybe ? So that each server can: A) use the same name/DN B) have ids that match exactly the local named account no matter how many different variants we have C) no management issues when the server is killed from the infrastructure as cn=config is local to that server and goes away with it. What do you think ? Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)?
On Thu, 19 Jun 2014, Simo Sorce wrote: I may need to revive my sysaccounts module... There is one more issue though, and this one really concerns me. If you need to put there multiple accounts because different servers have different local accounts, then you open up access to unrelated services. Because all these uids are shared on all systems. I think this kills my own proposal of sticking these entries in cn=sysaccounts. However we could have something in cn=config maybe ? So that each server can: A) use the same name/DN B) have ids that match exactly the local named account no matter how many different variants we have C) no management issues when the server is killed from the infrastructure as cn=config is local to that server and goes away with it. What do you think ? This is what Petr proposed too. 389-ds autobind code searches starting from a base defined in cn=config. IPA defines it to be $SUFFIX. If we move these entries to cn=config, they will not be found by the code in ds/ldap/servers/slapd/daemon.c:slapd_bind_local_user(). If we change a search base to something in cn=config, we wouldn't be able to use user accounts for autobind -- something which is possible right now. I'm not really concerned about user accounts' autobind but this is actually a behavior change for IPA. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)?
On Thu, 2014-06-19 at 17:47 +0300, Alexander Bokovoy wrote: On Thu, 19 Jun 2014, Simo Sorce wrote: I may need to revive my sysaccounts module... There is one more issue though, and this one really concerns me. If you need to put there multiple accounts because different servers have different local accounts, then you open up access to unrelated services. Because all these uids are shared on all systems. I think this kills my own proposal of sticking these entries in cn=sysaccounts. However we could have something in cn=config maybe ? So that each server can: A) use the same name/DN B) have ids that match exactly the local named account no matter how many different variants we have C) no management issues when the server is killed from the infrastructure as cn=config is local to that server and goes away with it. What do you think ? This is what Petr proposed too. 389-ds autobind code searches starting from a base defined in cn=config. IPA defines it to be $SUFFIX. If we move these entries to cn=config, they will not be found by the code in ds/ldap/servers/slapd/daemon.c:slapd_bind_local_user(). If we change a search base to something in cn=config, we wouldn't be able to use user accounts for autobind -- something which is possible right now. I'm not really concerned about user accounts' autobind but this is actually a behavior change for IPA. And I guess we can't list multiple bases for now ? We do not use autobind for anything now though, and I do not see it as useful for normal users on an IPA server, so I would be ok with the change, even if it breaks backward compatibility on masters themselves. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)?
On Thu, 19 Jun 2014, Simo Sorce wrote: On Thu, 2014-06-19 at 17:47 +0300, Alexander Bokovoy wrote: On Thu, 19 Jun 2014, Simo Sorce wrote: I may need to revive my sysaccounts module... There is one more issue though, and this one really concerns me. If you need to put there multiple accounts because different servers have different local accounts, then you open up access to unrelated services. Because all these uids are shared on all systems. I think this kills my own proposal of sticking these entries in cn=sysaccounts. However we could have something in cn=config maybe ? So that each server can: A) use the same name/DN B) have ids that match exactly the local named account no matter how many different variants we have C) no management issues when the server is killed from the infrastructure as cn=config is local to that server and goes away with it. What do you think ? This is what Petr proposed too. 389-ds autobind code searches starting from a base defined in cn=config. IPA defines it to be $SUFFIX. If we move these entries to cn=config, they will not be found by the code in ds/ldap/servers/slapd/daemon.c:slapd_bind_local_user(). If we change a search base to something in cn=config, we wouldn't be able to use user accounts for autobind -- something which is possible right now. I'm not really concerned about user accounts' autobind but this is actually a behavior change for IPA. And I guess we can't list multiple bases for now ? We do not use autobind for anything now though, and I do not see it as useful for normal users on an IPA server, so I would be ok with the change, even if it breaks backward compatibility on masters themselves. The only thing we use is root autobind which is handled by a separate mechanism, I think. Thus, it suits me. Petr, can you please make a ticket? -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)?
On 06/19/2014 04:58 PM, Alexander Bokovoy wrote: On Thu, 19 Jun 2014, Simo Sorce wrote: On Thu, 2014-06-19 at 17:47 +0300, Alexander Bokovoy wrote: On Thu, 19 Jun 2014, Simo Sorce wrote: I may need to revive my sysaccounts module... There is one more issue though, and this one really concerns me. If you need to put there multiple accounts because different servers have different local accounts, then you open up access to unrelated services. Because all these uids are shared on all systems. I think this kills my own proposal of sticking these entries in cn=sysaccounts. However we could have something in cn=config maybe ? So that each server can: A) use the same name/DN B) have ids that match exactly the local named account no matter how many different variants we have C) no management issues when the server is killed from the infrastructure as cn=config is local to that server and goes away with it. What do you think ? This is what Petr proposed too. 389-ds autobind code searches starting from a base defined in cn=config. IPA defines it to be $SUFFIX. If we move these entries to cn=config, they will not be found by the code in ds/ldap/servers/slapd/daemon.c:slapd_bind_local_user(). If we change a search base to something in cn=config, we wouldn't be able to use user accounts for autobind -- something which is possible right now. I'm not really concerned about user accounts' autobind but this is actually a behavior change for IPA. And I guess we can't list multiple bases for now ? We do not use autobind for anything now though, and I do not see it as useful for normal users on an IPA server, so I would be ok with the change, even if it breaks backward compatibility on masters themselves. The only thing we use is root autobind which is handled by a separate mechanism, I think. Thus, it suits me. Petr, can you please make a ticket? How can you be sure that people do not already use the autobind feature? IMO, it is a bad move to just break it because we have no better idea how to handle named autobind. I would rather like to see improved autobind capability in 389-ds-base which would allow us to do the autobind configuration in cn=config and do entries like: uidnumber=25+gidnumber=25,cn=autobind,cn=config ... binddn: krbprincipalname=DNS/ipa.server.test,cn=computers... And thus have a per-server configuration without breaking existent functionality. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)?
On 19.6.2014 17:06, Martin Kosek wrote: On 06/19/2014 04:58 PM, Alexander Bokovoy wrote: On Thu, 19 Jun 2014, Simo Sorce wrote: On Thu, 2014-06-19 at 17:47 +0300, Alexander Bokovoy wrote: On Thu, 19 Jun 2014, Simo Sorce wrote: I may need to revive my sysaccounts module... There is one more issue though, and this one really concerns me. If you need to put there multiple accounts because different servers have different local accounts, then you open up access to unrelated services. Because all these uids are shared on all systems. I think this kills my own proposal of sticking these entries in cn=sysaccounts. However we could have something in cn=config maybe ? So that each server can: A) use the same name/DN B) have ids that match exactly the local named account no matter how many different variants we have C) no management issues when the server is killed from the infrastructure as cn=config is local to that server and goes away with it. What do you think ? This is what Petr proposed too. 389-ds autobind code searches starting from a base defined in cn=config. IPA defines it to be $SUFFIX. If we move these entries to cn=config, they will not be found by the code in ds/ldap/servers/slapd/daemon.c:slapd_bind_local_user(). If we change a search base to something in cn=config, we wouldn't be able to use user accounts for autobind -- something which is possible right now. I'm not really concerned about user accounts' autobind but this is actually a behavior change for IPA. And I guess we can't list multiple bases for now ? We do not use autobind for anything now though, and I do not see it as useful for normal users on an IPA server, so I would be ok with the change, even if it breaks backward compatibility on masters themselves. The only thing we use is root autobind which is handled by a separate mechanism, I think. Thus, it suits me. Petr, can you please make a ticket? How can you be sure that people do not already use the autobind feature? IMO, it is a bad move to just break it because we have no better idea how to handle named autobind. I would rather like to see improved autobind capability in 389-ds-base which would allow us to do the autobind configuration in cn=config and do entries like: uidnumber=25+gidnumber=25,cn=autobind,cn=config ... binddn: krbprincipalname=DNS/ipa.server.test,cn=computers... And thus have a per-server configuration without breaking existent functionality. That is my favorite! (Which is not surprising, I was proposing exactly that almost 5 hours ago :-)) Anyway, the ticket is https://fedorahosted.org/freeipa/ticket/4388 -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)?
On Thu, 19 Jun 2014, Martin Kosek wrote: On 06/19/2014 04:58 PM, Alexander Bokovoy wrote: On Thu, 19 Jun 2014, Simo Sorce wrote: On Thu, 2014-06-19 at 17:47 +0300, Alexander Bokovoy wrote: On Thu, 19 Jun 2014, Simo Sorce wrote: I may need to revive my sysaccounts module... There is one more issue though, and this one really concerns me. If you need to put there multiple accounts because different servers have different local accounts, then you open up access to unrelated services. Because all these uids are shared on all systems. I think this kills my own proposal of sticking these entries in cn=sysaccounts. However we could have something in cn=config maybe ? So that each server can: A) use the same name/DN B) have ids that match exactly the local named account no matter how many different variants we have C) no management issues when the server is killed from the infrastructure as cn=config is local to that server and goes away with it. What do you think ? This is what Petr proposed too. 389-ds autobind code searches starting from a base defined in cn=config. IPA defines it to be $SUFFIX. If we move these entries to cn=config, they will not be found by the code in ds/ldap/servers/slapd/daemon.c:slapd_bind_local_user(). If we change a search base to something in cn=config, we wouldn't be able to use user accounts for autobind -- something which is possible right now. I'm not really concerned about user accounts' autobind but this is actually a behavior change for IPA. And I guess we can't list multiple bases for now ? We do not use autobind for anything now though, and I do not see it as useful for normal users on an IPA server, so I would be ok with the change, even if it breaks backward compatibility on masters themselves. The only thing we use is root autobind which is handled by a separate mechanism, I think. Thus, it suits me. Petr, can you please make a ticket? How can you be sure that people do not already use the autobind feature? IMO, it is a bad move to just break it because we have no better idea how to handle named autobind. autobind is a feature of 389-ds only. Howard Chu (OpenLDAP) considers it a violation of RFC4513 and if we limit who can use it I don't think anyone will be crying too much. I would rather like to see improved autobind capability in 389-ds-base which would allow us to do the autobind configuration in cn=config and do entries like: uidnumber=25+gidnumber=25,cn=autobind,cn=config ... binddn: krbprincipalname=DNS/ipa.server.test,cn=computers... And thus have a per-server configuration without breaking existent functionality. That would work too but the main ide is to simply change our, IPA, defaults, rather than implementing something new. If somebody relies on autobind to work for regular users on IPA masters without explicit authentication, it is already a question of a security breach. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)?
On 06/19/2014 09:16 AM, Alexander Bokovoy wrote: On Thu, 19 Jun 2014, Martin Kosek wrote: On 06/19/2014 04:58 PM, Alexander Bokovoy wrote: On Thu, 19 Jun 2014, Simo Sorce wrote: On Thu, 2014-06-19 at 17:47 +0300, Alexander Bokovoy wrote: On Thu, 19 Jun 2014, Simo Sorce wrote: I may need to revive my sysaccounts module... There is one more issue though, and this one really concerns me. If you need to put there multiple accounts because different servers have different local accounts, then you open up access to unrelated services. Because all these uids are shared on all systems. I think this kills my own proposal of sticking these entries in cn=sysaccounts. However we could have something in cn=config maybe ? So that each server can: A) use the same name/DN B) have ids that match exactly the local named account no matter how many different variants we have C) no management issues when the server is killed from the infrastructure as cn=config is local to that server and goes away with it. What do you think ? This is what Petr proposed too. 389-ds autobind code searches starting from a base defined in cn=config. IPA defines it to be $SUFFIX. If we move these entries to cn=config, they will not be found by the code in ds/ldap/servers/slapd/daemon.c:slapd_bind_local_user(). If we change a search base to something in cn=config, we wouldn't be able to use user accounts for autobind -- something which is possible right now. I'm not really concerned about user accounts' autobind but this is actually a behavior change for IPA. And I guess we can't list multiple bases for now ? We do not use autobind for anything now though, and I do not see it as useful for normal users on an IPA server, so I would be ok with the change, even if it breaks backward compatibility on masters themselves. The only thing we use is root autobind which is handled by a separate mechanism, I think. Thus, it suits me. Petr, can you please make a ticket? How can you be sure that people do not already use the autobind feature? IMO, it is a bad move to just break it because we have no better idea how to handle named autobind. autobind is a feature of 389-ds only. Howard Chu (OpenLDAP) considers it a violation of RFC4513 A violation even when using EXTERNAL bind? and if we limit who can use it I don't think anyone will be crying too much. If we change it to be incompatible, we may break existing _389_ customers, even if they are potentially using something that violates RFC4513. I would rather like to see improved autobind capability in 389-ds-base which would allow us to do the autobind configuration in cn=config and do entries like: uidnumber=25+gidnumber=25,cn=autobind,cn=config ... binddn: krbprincipalname=DNS/ipa.server.test,cn=computers... And thus have a per-server configuration without breaking existent functionality. That would work too but the main ide is to simply change our, IPA, defaults, rather than implementing something new. If somebody relies on autobind to work for regular users on IPA masters without explicit authentication, By explicit authentication do you mean using EXTERNAL bind? it is already a question of a security breach. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)?
On Thu, 19 Jun 2014, Rich Megginson wrote: On 06/19/2014 09:16 AM, Alexander Bokovoy wrote: On Thu, 19 Jun 2014, Martin Kosek wrote: On 06/19/2014 04:58 PM, Alexander Bokovoy wrote: On Thu, 19 Jun 2014, Simo Sorce wrote: On Thu, 2014-06-19 at 17:47 +0300, Alexander Bokovoy wrote: On Thu, 19 Jun 2014, Simo Sorce wrote: I may need to revive my sysaccounts module... There is one more issue though, and this one really concerns me. If you need to put there multiple accounts because different servers have different local accounts, then you open up access to unrelated services. Because all these uids are shared on all systems. I think this kills my own proposal of sticking these entries in cn=sysaccounts. However we could have something in cn=config maybe ? So that each server can: A) use the same name/DN B) have ids that match exactly the local named account no matter how many different variants we have C) no management issues when the server is killed from the infrastructure as cn=config is local to that server and goes away with it. What do you think ? This is what Petr proposed too. 389-ds autobind code searches starting from a base defined in cn=config. IPA defines it to be $SUFFIX. If we move these entries to cn=config, they will not be found by the code in ds/ldap/servers/slapd/daemon.c:slapd_bind_local_user(). If we change a search base to something in cn=config, we wouldn't be able to use user accounts for autobind -- something which is possible right now. I'm not really concerned about user accounts' autobind but this is actually a behavior change for IPA. And I guess we can't list multiple bases for now ? We do not use autobind for anything now though, and I do not see it as useful for normal users on an IPA server, so I would be ok with the change, even if it breaks backward compatibility on masters themselves. The only thing we use is root autobind which is handled by a separate mechanism, I think. Thus, it suits me. Petr, can you please make a ticket? How can you be sure that people do not already use the autobind feature? IMO, it is a bad move to just break it because we have no better idea how to handle named autobind. autobind is a feature of 389-ds only. Howard Chu (OpenLDAP) considers it a violation of RFC4513 A violation even when using EXTERNAL bind? Howard's line of thought was that RFC4513 requires to have anonymous bind when no credentials were provided. Autobind makes implicit conversion to authenticated bind here. I know that at the time of discussion (~2007) 389-ds team's approach was that LDAPI is not really LDAP protocol wise and it could deviate here. and if we limit who can use it I don't think anyone will be crying too much. If we change it to be incompatible, we may break existing _389_ customers, even if they are potentially using something that violates RFC4513. I would rather like to see improved autobind capability in 389-ds-base which would allow us to do the autobind configuration in cn=config and do entries like: uidnumber=25+gidnumber=25,cn=autobind,cn=config ... binddn: krbprincipalname=DNS/ipa.server.test,cn=computers... And thus have a per-server configuration without breaking existent functionality. That would work too but the main ide is to simply change our, IPA, defaults, rather than implementing something new. If somebody relies on autobind to work for regular users on IPA masters without explicit authentication, By explicit authentication do you mean using EXTERNAL bind? I mean that by becoming a non-privileged user on a 389-ds server that has anonymous bind disabled will give you non-authenticated access to LDAP store through autobind+LDAPI. Non-authenticated in terms of not providing any authentication data to LDAP store. So breaking a user account is enough to get data (subject to ACIs, of course), you don't need to have any idea of what credentials the user should have. It is question of policies to be set and for FreeIPA masters I would argue that the policy should be to prevent non-privileged users to do autobind+LDAPI unless it is explicitly allowed by the configuration for that specific user. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)?
On Thu, 2014-06-19 at 17:06 +0200, Martin Kosek wrote: On 06/19/2014 04:58 PM, Alexander Bokovoy wrote: On Thu, 19 Jun 2014, Simo Sorce wrote: On Thu, 2014-06-19 at 17:47 +0300, Alexander Bokovoy wrote: On Thu, 19 Jun 2014, Simo Sorce wrote: I may need to revive my sysaccounts module... There is one more issue though, and this one really concerns me. If you need to put there multiple accounts because different servers have different local accounts, then you open up access to unrelated services. Because all these uids are shared on all systems. I think this kills my own proposal of sticking these entries in cn=sysaccounts. However we could have something in cn=config maybe ? So that each server can: A) use the same name/DN B) have ids that match exactly the local named account no matter how many different variants we have C) no management issues when the server is killed from the infrastructure as cn=config is local to that server and goes away with it. What do you think ? This is what Petr proposed too. 389-ds autobind code searches starting from a base defined in cn=config. IPA defines it to be $SUFFIX. If we move these entries to cn=config, they will not be found by the code in ds/ldap/servers/slapd/daemon.c:slapd_bind_local_user(). If we change a search base to something in cn=config, we wouldn't be able to use user accounts for autobind -- something which is possible right now. I'm not really concerned about user accounts' autobind but this is actually a behavior change for IPA. And I guess we can't list multiple bases for now ? We do not use autobind for anything now though, and I do not see it as useful for normal users on an IPA server, so I would be ok with the change, even if it breaks backward compatibility on masters themselves. The only thing we use is root autobind which is handled by a separate mechanism, I think. Thus, it suits me. Petr, can you please make a ticket? How can you be sure that people do not already use the autobind feature? Regular users should nto really log into the master anyway, so unless we are using this feature in one of the IPA components I would say it is an unsupported usage (and highly unlikely anyway as it is not a well know feature). IMO, it is a bad move to just break it because we have no better idea how to handle named autobind. Oh but we do have a better idea :) I would rather like to see improved autobind capability in 389-ds-base which would allow us to do the autobind configuration in cn=config and do entries like: uidnumber=25+gidnumber=25,cn=autobind,cn=config ... binddn: krbprincipalname=DNS/ipa.server.test,cn=computers... And thus have a per-server configuration without breaking existent functionality. I do not think it is worth it. Yes we could maintain the feature, but I would worry about adding code only if we have someone with a good use case for using regular shared users and autobind and not being able to migrate to add an entry in cn=config. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)?
On Thu, 2014-06-19 at 09:23 -0600, Rich Megginson wrote: and if we limit who can use it I don't think anyone will be crying too much. If we change it to be incompatible, we may break existing _389_ customers, even if they are potentially using something that violates RFC4513. I am not proposing to change anything in 389ds, just the configuration of the suffix to look at so we are not breaking any _389_ customer. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
