openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

(ITS#5815) typo in os-ip.c (MAXHOSTNAMELEN)
by h.b.furuseth＠usit.uio.no 16 Nov '08

16 Nov '08

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard #elif defined( MAXHOSTNAMELEN should be #elif defined( MAXHOSTNAMELEN ) Reported in Debian bug 505421. Fixing.

1 0

Re: (ITS#5805) Problem when modifying access control
by ando＠sys-net.it 16 Nov '08

16 Nov '08

emmanuel.duru(a)atosorigin.com wrote: > Full_Name: Emmanuel Duru > Version: 2.4.11 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.78.0.137) > > > I have a single BDB database directory with root DN as a physical entry. My > access control is defined as follows in olcDatabase={-1}frontend: > olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * no > ne > olcAccess: {1}to dn=cn=manager,c=fr by self write by * none > olcAccess: {2}to * by self write by users read by anonymous read by * none > > I perform a modify operation as follows: > dn: olcDatabase={-1}frontend,cn=config > changetype: modify > replace: olcAccess > olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * no > ne > olcAccess: {1}to dn=cn=manager,c=fr by self write by * none > olcAccess: {2}to * by self write by users read by anonymous read by * none > > dn: olcDatabase={0}config,cn=config > changetype: modify > replace: olcAccess > olcAccess: {0}to * by * none > - > replace: olcRootDN > olcRootDN: cn=manager,c=fr > > then I can not bind any more to the directory (invalid credentials). > The log says (do notice the line dn: [1]... with non printable characters): > do_bind: version=3 dn="cn=manager,c=fr" method=128 > ==> bdb_bind: dn: cn=manager,c=fr > bdb_dn2entry("cn=manager,c=fr") > => access_allowed: auth access to "cn=manager,c=fr" "userPassword" requested > => dn: [1] <some non printable characters>anager,c=fr > => acl_get: [2] attr userPassword > => slap_access_allowed: result not in cache (userPassword) > => acl_mask: access to entry "cn=manager,c=fr", attr "userPassword" requested > => acl_mask: to value by "", (=0) > <= check a_dn_pat: * > <= acl_mask: [1] applying none(=0) (stop) > <= acl_mask: [1] mask: none(=0) > => slap_access_allowed: auth access denied by none(=0) > => access_allowed: no more rules > > When I stop the directory, the log says (filter_free lines may vary): > bdb_db_close: database "c=fr": alock_close failed > filter_free: unknown filter type=20224 > filter_free: unknown filter type=496 > slapd stopped. > filter_free: unknown filter type=29776 > filter_free: unknown filter type=13944 > filter_free: unknown filter type=29496 > > When I restart slapd, all is fine: the access control is OK and I can bind. I can't confirm your report with HEAD code. I suggest you retry with either 2.4.12 or (better) re24, which is about to be released as 2.4.13. I note that by performing the operations you indicate, the cn=config database (dn: olcDatabase={0}config,cn=config) ends up in an inconsistent state, because the rootdn does not belong to its naming context, but the rootpw is set, which should not be allowed. A check for this does not exist, while it should. In any case, this is harmless. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5814) concurrent access to connections
by ando＠sys-net.it 16 Nov '08

16 Nov '08

ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD/re24 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.72.89.40) > Submitted by: ando > > > There is code that accesses c_conn_state and c_struct_state while not adequately > mutex-protected. In most cases, this code basically consists in assertions, so > we risk a core dump because of an assertion on non-mutex protected data. This > is the case (as happened to me) of connection_next(). > > I have a fix for the case I noticed, with two unhandled asserts (marked with a > FIXME) because I'm not sure whether it's worth to add extra mutexes just to be > able to safely assert, or remove assertions. > > Committing the fix; there might be more. Please check. I noticed this while testing concurrency for re24; here is the relevant portion of the core dump: (gdb) bt #0 0x00483402 in __kernel_vsyscall () #1 0x00c9ad20 in raise () from /lib/libc.so.6 #2 0x00c9c631 in abort () from /lib/libc.so.6 #3 0x00c9416b in __assert_fail () from /lib/libc.so.6 #4 0x08084b80 in connection_next (c=0x0, index=0xb62e3d8c) at ../../../ldap-2.4-src/servers/slapd/connection.c:871 #5 0x081a810c in monitor_subsys_conn_update (op=0x8a145f0, rs=0xb62e5128, e=0x896632c) at ../../../../ldap-2.4-src/servers/slapd/back-monitor/conn.c:230 <snip> (gdb) f 4 #4 0x08084b80 in connection_next (c=0x0, index=0xb62e3d8c) at ../../../ldap-2.4-src/servers/slapd/connection.c:871 (gdb) p connections[*index] $1 = {c_struct_state = 2, c_conn_state = 1, c_conn_idx = 19, c_sd = 19, <snip> Cheers, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5814) concurrent access to connections
by ando＠sys-net.it 16 Nov '08

16 Nov '08

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando There is code that accesses c_conn_state and c_struct_state while not adequately mutex-protected. In most cases, this code basically consists in assertions, so we risk a core dump because of an assertion on non-mutex protected data. This is the case (as happened to me) of connection_next(). I have a fix for the case I noticed, with two unhandled asserts (marked with a FIXME) because I'm not sure whether it's worth to add extra mutexes just to be able to safely assert, or remove assertions. Committing the fix; there might be more. Please check. p.

1 0

Re: (ITS#5812) New option to disable SASL host canonicalization
by geert＠boskant.nl 16 Nov '08

16 Nov '08

------=_Part_45002_9684276.1226844472048 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Sun, Nov 16, 2008 at 2:25 AM, Howard Chu <hyc(a)symas.com> wrote: > That is completely irrelevant. If a given site has a misconfigured DNS, > whether or not it uses integrity or privacy checks on the DNS service, it is > still misconfigured. My point was that even if your reverse DNS mappings are correct, this is not a sufficient base for canonicalization. as it would have to be secure too. Or would you consider a DNS setup without DNSSEC to be broken too? In that case 99% of all setups would be broken. To maximize interoperability and security, applications SHOULD provide > security > mechanisms with names that result from folding the user- entered name to > lowercase without performing any other modifications or canonicalization. > Wishful thinking; that recommendation is at least 15 years too late and the > majority of Kerberized software isn't going to change to accommodate it. Not everybody needs to do this at once. MIT Kerberos already supports multiple ways of canonicalizing, including reverse DNS and the Canonicalize bit. Applications can start supporting this one by one. > In the meantime, the arguments about secure DNS are pure red herrings: > 1. if your DNS has been hijacked, it's most likely that you'll be directed > to a rogue KDC first, so the question of which service you're talking to is > moot. Wrong. Kerberos protects against that. A rogue KDC would not have your secret key and therefore is unable to generate a correct ticket for you. This would get noticed immediately by the library and the handshake would be aborted. > 2. there's nothing to gain from directing you to a rogue service, since > if you managed to contact the legitimate KDC, you're going to have a service > ticket that can only be decoded by the legitimate service principal. > On the other hand, if the rogue service is actually a valid principal in > your trusted KDC's database, then you clearly have an administrative problem > in your KDC. > Ok, so let me show you a real attack scenario as it indeed requires one copromised server. Supose an attacker has compromised one system in a Kerberos realm that was running a Kerberos service. The attacker can now spoof reverse DNS based on any of the available methods, and use it to redirect any internal service to a service on his server. He now puts up a mock up of the original service on the comprimised server, and coaxes users into entering any data that he would only enter in the real service. He can use this data to expand his compromised systems. If you would use secure canonicalization, the above cannot happen. It limits the scope of a compromise to that server. Without security canonicalization this is basically all-or-nothing security which is bad. This patch attempts to provide a band-aid without actually solving the real > problem. It merely masks the problem temporarily, until it gets even worse. No. From a security point it limits the impact of a comprimise of one server in your environment. From other point of views it helps environments that use the current best practise albeit broken method of canonicalizing host name. > This request is akin to asking for "schemachecking off" to be resurrected. > This sort of feature is always requested because of an existing mistake, and > allowing it only compounds the mistake further. We should never make it > easier for admins to make and ignore mistakes. This analogy does not work. The proposed option provides the possibility to implement a recommendation from the Kerberos RFC. Where in the LDAP RFCs does it say that it is recommended to turn schemachecking off? Regards,Geert ------=_Part_45002_9684276.1226844472048 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Sun, Nov 16, 2008 at 2:25 AM, Howard Chu <span dir="ltr"><<a href="mailto:hyc@symas.com">hyc(a)symas.com</a>></span> wrote:<br><div class="gmail_quote"> <br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> That is completely irrelevant. If a given site has a misconfigured DNS, whether or not it uses integrity or privacy checks on the DNS service, it is still misconfigured.</blockquote><div class="Ih2E3d"><br>My point was that even if your reverse DNS mappings are correct, this is not a sufficient base for canonicalization. as it would have to be secure too. Or would you consider a DNS setup without DNSSEC to be broken too? In that case 99% of all setups would be broken.<br> <br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">   To maximize interoperability and security, applications SHOULD provide security<br>   mechanisms with names that result from folding the user- entered name to<br>   lowercase without performing any other modifications or canonicalization.<br> </blockquote> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Wishful thinking; that recommendation is at least 15 years too late and the majority of Kerberized software isn't going to change to accommodate it.</blockquote><div><br>Not everybody needs to do this at once. MIT Kerberos already supports multiple ways of canonicalizing, including reverse DNS and the Canonicalize bit. Applications can start supporting this one by one.<br> </div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> In the meantime, the arguments about secure DNS are pure red herrings:<br>  1. if your DNS has been hijacked, it's most likely that you'll be directed to a rogue KDC first, so the question of which service you're talking to is moot.</blockquote><div><br>Wrong. Kerberos protects against that. A rogue KDC would not have your secret key and therefore is unable to generate a correct ticket for you. This would get noticed immediately by the library and the handshake would be aborted.<br>  <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">  2. there's nothing to gain from directing you to a rogue service, since if you managed to contact the legitimate KDC, you're going to have a service ticket that can only be decoded by the legitimate service principal.</blockquote> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>  On the other hand, if the rogue service is actually a valid principal in your trusted KDC's database, then you clearly have an administrative problem in your KDC.<br></blockquote><div><br>Ok, so let me show you a real attack scenario as it indeed requires one copromised server. Supose an attacker has compromised one system in a Kerberos realm that was running a Kerberos service. The attacker can now spoof reverse DNS based on any of the available methods, and use it to redirect any internal service to a service on his server. He now puts up a mock up of the original service on the comprimised server, and coaxes users into entering any data that he would only enter in the real service. He can use this data to expand his compromised systems.<br> <br>If you would use secure canonicalization, the above cannot happen. It limits the scope of a compromise to that server. Without security canonicalization this is basically all-or-nothing security which is bad.<br><br></div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> This patch attempts to provide a band-aid without actually solving the real problem. It merely masks the problem temporarily, until it gets even worse.</blockquote><div><br>No. From a security point it limits the impact of a comprimise of one server in your environment. From other point of views it helps environments that use the current best practise albeit broken method of canonicalizing host name. <br> </div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> This request is akin to asking for "schemachecking off" to be resurrected. This sort of feature is always requested because of an existing mistake, and allowing it only compounds the mistake further. We should never make it easier for admins to make and ignore mistakes.</blockquote> <div><br>This analogy does not work. The proposed option provides the possibility to implement a recommendation from the Kerberos RFC. Where in the LDAP RFCs does it say that it is recommended to turn schemachecking off?<br> <br>Regards,Geert</div></div><br> ------=_Part_45002_9684276.1226844472048--

1 0

(ITS#5813) limits with empty dn mostly do not work
by h.b.furuseth＠usit.uio.no 15 Nov '08

15 Nov '08

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: URL: http://folk.uio.no/hbf/OpenLDAP/limits-empty.txt Submission from: (NULL) (129.240.6.233) Submitted by: hallvard Limits set as limits dn.<exact/base/onelevel/subtree/children>="" ... are never used: - exact/base: it only matches the empty Bind DN, which in slapd means anonymous, for which limits_get() does not test dn.<exact/base>. - onelevel/subtree/children: limits_get() does not use these for the empty Bind DN, and it expects a non-empty Bind DNs to end with ",". Some cases above work with dn.this.foo instead of dn.foo. limits dn.regex="" works (equivalent to limits users). limits dn.group="" may work if the admin stuffs group members into the root DSE. (I haven't tested.) My preferred fixes: - For dn.this, fix the above since baseDN "" makes sense and dn.this is new anyway, so there is no backwards compatibility to worry about. - For dn.self, fail parsing of the limit cases above that do not work. Otherwise the dn.this change could invoke new functionality in existing configurations. We won't know what the admin meant with DN "" - did he mean to include anonymous? That is not an entry with a DN, but is stored in slapd and the Bind request as the empty DN. Also limits parsing vs. anonymous connections is dubious today anyway: dn.<anything>=* or dn.regex=.* are special-cased to match anonymous, while dn="" does not. Also dn.children=* should not match anonymous but does. So it seems to me that any cleanup should consist of first removing strange cases, and if anyone want them reintroduce them in a later branch with correct semantics. I enclose a suggested fix. Giving Pierangelo at least time to repond since he either agreed or disagreed with this in this message, I'm not sure which:-) http://www.openldap.org/lists/openldap-devel/200810/msg00116.html I knew there was an issue about these limits I had forgotten.

1 0

Re: (ITS#5812) New option to disable SASL host canonicalization
by hyc＠symas.com 15 Nov '08

15 Nov '08

Geert Jansen wrote: > Well .. I don't think my patch qualifies as breaking software to work > with broken software. The patch allows OpenLDAP applications to use > alternative ways for name canonicalization. At this moment this is not > possible because OpenLDAP is hard coded to canonicalize names with > reverse DNS. This means I cannot use the option that MIT Kerberos > provides me to disable this (rdns = no), as host names have already been > reverse mapped by OpenLDAP before they are passed into Kerberos. > > I agree with you that reverse DNS should be correct. I just mentioned > the fact that many reverse DNS setups are broken as an example of why it > can be problematic. The fact that many environments are misconfigured is not a good reason to change the current behavior. > Another reason why canonicalization based on reverse > DNS is problematic is that it requires secure DNS to be secure. RFC4120 > mentions this: That is completely irrelevant. If a given site has a misconfigured DNS, whether or not it uses integrity or privacy checks on the DNS service, it is still misconfigured. > Implementations of Kerberos and protocols based on Kerberos MUST NOT > use insecure DNS queries to canonicalize the hostname components of > the service principal names (i.e., they MUST NOT use insecure DNS > queries to map one name to another to determine the host part of the > principal name with which one is to communicate). > The same RFC recommends in fact that applications do not canonicalize > host names at all: > > To maximize interoperability and security, applications SHOULD provide security > mechanisms with names that result from folding the user- entered name to > lowercase without performing any other modifications or canonicalization. Wishful thinking; that recommendation is at least 15 years too late and the majority of Kerberized software isn't going to change to accommodate it. In the meantime, the arguments about secure DNS are pure red herrings: 1. if your DNS has been hijacked, it's most likely that you'll be directed to a rogue KDC first, so the question of which service you're talking to is moot. 2. there's nothing to gain from directing you to a rogue service, since if you managed to contact the legitimate KDC, you're going to have a service ticket that can only be decoded by the legitimate service principal. On the other hand, if the rogue service is actually a valid principal in your trusted KDC's database, then you clearly have an administrative problem in your KDC. This patch attempts to provide a band-aid without actually solving the real problem. It merely masks the problem temporarily, until it gets even worse. This request is akin to asking for "schemachecking off" to be resurrected. This sort of feature is always requested because of an existing mistake, and allowing it only compounds the mistake further. We should never make it easier for admins to make and ignore mistakes. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5812) New option to disable SASL host canonicalization
by geert＠boskant.nl 15 Nov '08

15 Nov '08

------=_Part_39674_19690948.1226797622518 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Sat, Nov 15, 2008 at 6:20 PM, Howard Chu <hyc(a)symas.com> wrote: > > Breaking more software to use it with already broken software is, in a > word, stupid. The standard practice for Kerberos requires you to have > consistent forward and reverse DNS lookups. Sysadmins who are afraid to > administer their software should either change their software or change > their jobs. Well .. I don't think my patch qualifies as breaking software to work with broken software. The patch allows OpenLDAP applications to use alternative ways for name canonicalization. At this moment this is not possible because OpenLDAP is hard coded to canonicalize names with reverse DNS. This means I cannot use the option that MIT Kerberos provides me to disable this (rdns = no), as host names have already been reverse mapped by OpenLDAP before they are passed into Kerberos. I agree with you that reverse DNS should be correct. I just mentioned the fact that many reverse DNS setups are broken as an example of why it can be problematic. Another reason why canonicalization based on reverse DNS is problematic is that it requires secure DNS to be secure. RFC4120 mentions this: Implementations of Kerberos and protocols based on Kerberos MUST NOT use insecure DNS queries to canonicalize the hostname components of the service principal names (i.e., they MUST NOT use insecure DNS queries to map one name to another to determine the host part of the principal name with which one is to communicate). The same RFC recommends in fact that applications do not canonicalize host names at all: To maximize interoperability and security, applications SHOULD provide security mechanisms with names that result from folding the user- entered name to lowercase without performing any other modifications or canonicalization. My patch implements this behaviour, as an option. Regards, Geert ------=_Part_39674_19690948.1226797622518 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Sat, Nov 15, 2008 at 6:20 PM, Howard Chu <span dir="ltr"><<a href="mailto:hyc@symas.com" target="_blank">hyc(a)symas.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <br> Breaking more software to use it with already broken software is, in a word, stupid. The standard practice for Kerberos requires you to have consistent forward and reverse DNS lookups. Sysadmins who are afraid to administer their software should either change their software or change their jobs.</blockquote> <div><br>Well .. I don't think my patch qualifies as breaking software to work with broken software. The patch allows OpenLDAP applications to use alternative ways for name canonicalization. At this moment this is not possible because OpenLDAP is hard coded to canonicalize names with reverse DNS. This means I cannot use the option that MIT Kerberos provides me to disable this (rdns = no), as host names have already been reverse mapped by OpenLDAP before they are passed into Kerberos.<br> <br>I agree with you that reverse DNS should be correct. I just mentioned the fact that many reverse DNS setups are broken as an example of why it can be problematic. Another reason why canonicalization based on reverse DNS is problematic is that it requires secure DNS to be secure. RFC4120 mentions this:<br> <br><pre> Implementations of Kerberos and protocols based on Kerberos MUST NOT<br> use insecure DNS queries to canonicalize the hostname components of<br> the service principal names (i.e., they MUST NOT use insecure DNS<br> queries to map one name to another to determine the host part of the<br> principal name with which one is to communicate). </pre><br>The same RFC recommends in fact that applications do not canonicalize host names at all:<br> <br><pre> To maximize interoperability and security, applications SHOULD provide security<br> mechanisms with names that result from folding the user- entered name to<br> lowercase without performing any other modifications or canonicalization.<br> </pre><br>My patch implements this behaviour, as an option.<br><br>Regards,<br>Geert</div></div><br> ------=_Part_39674_19690948.1226797622518--

1 0

RE: (ITS#5788) Search does not work with nested naming contexts
by h.b.furuseth＠usit.uio.no 15 Nov '08

15 Nov '08

I wrote: > "LDAP operations normally access only one database. However > databases that provide related naming contexts ("suffixes") may be > glued together with the /subordinate/ keyword. Some other features > such as access controls and the /translucent/ overlay can also > involve multiple databases." I've added similar text to slapd.conf.5, but didn't see a suitable place for it in slapd-config.5. (Except in olcSubordinate description itself, where it is already mentioned). Admin guide fix still needed. -- Hallvard

1 0

Re: (ITS#5812) New option to disable SASL host canonicalization
by hyc＠symas.com 15 Nov '08

15 Nov '08

geert(a)boskant.nl wrote: > Full_Name: Geert Jansen > Version: 2.4 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/geert-jansen-081115.patch > Submission from: (NULL) (12.230.186.195) > > > This is a resubmission of my earlier patch in [1]. I'm asking for this patch to > be included into OpenLDAP. > > The patch adds an LDAP option called LDAP_OPT_X_SASL_NOCANON to disable host > name canonicalization using reverse DNS for the host name that is passed into > SASL. Instead, it passes verbatim the host name part from the LDAP URI and lets > SASL do the canonicalization. The option is disabled by default. > > Kerberos requires a canonical host name to work. Traditionally, host name > canonicalization has been done using reverse DNS. However, this is problematic. > See the comment below from the MIT Kerberos source on this subject: > > /* XXX: This is *so* bogus. There are several cases where > this won't get us the canonical name of the host, but > this is what we've trained people to expect. We'll > probably fix it at some point, but let's try to > preserve the current behavior and only shake things up > once when it comes time to fix this lossage. */ > > Since some time MIT Kerberos has support for server-side canonicalization which > is an alternative for the DNS based scheme. By default it uses both, but with an > option "rdns = no", reverse DNS can be disabled. > > The use case for this is environments that do not have reverse DNS set up > correctly. Especially in Windows Active Directory environments this is very > common. Administrators are afraid to enable scavenging for their zones, and > therefore any server IP change will leave a stale PTR record in place. This > breaks reverse DNS based canonicalization if the IP adress is reassigned. Breaking more software to use it with already broken software is, in a word, stupid. The standard practice for Kerberos requires you to have consistent forward and reverse DNS lookups. Sysadmins who are afraid to administer their software should either change their software or change their jobs. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs