('binary' encoding is not supported, stored as-is) Issue: Any user can login into any GroupWise account. Environment: GroupWise 6 Post Office using LDAP authentication AND security configuration of PostOffice leaves LDAP User Name and Password fields blank in the Post Office Agent object in ConsoleOne. Exploit: Run GroupWise as any user (either "grpwise /@u-?") OR if you are not NDS authenticated, whatever the registry has stored as the last person who logged into GroupWise) and leave the password blank. Hit enter a couple of times and you will get right into the account. Details: TID 10067921 should be posted as it shows the steps you need to take to leave LDAP authentication on, and not have the password problem. When I spoke to the technician on the 14th it was supposed to have been posted, but it hasn't yet. Fix: A. Novell has developed a workaround to this issue in the LDAP spec to prevent GroupWise accounts from being accessed without a password. This fix is found in the Field Test File FGW62N4.EXE. This can be found at support.novell.com and searching for the filename. Pro: solves problem, retains current password functionality. Con: New code comes with possible stability issues. B. Without implementing the new code, the issue can be resolved as follows: Fill in the LDAP User Name and Password fields in the Post Office Agent object in ConsoleOne. The LDAP User Name is the eDirectory account that the POA, the Internet Agent, and the WebAccess Agent can use to log in to the LDAP server in order to authenticate GroupWise users. Pro: this approach to LDAP authentication is faster and requires fewer connections to the LDAP server than if each GroupWise user authenticates to the LDAP server individually. Con: From within GroupWise, users will not be able to use grace logins, nor will they be able to change their LDAP passwords. Technical details (in Novell's words): This isn't technically a bug, but a configuration issue. In accordance with the LDAP v3 RFC 2251, an LDAP bind in which a username is provided but a password is not [ie. blank] is treated as an anonymous bind. This means that a bind is granted to users providing a username but no password. The bind granted is an anonymous bind but, based on limitations in the LDAP spec, most LDAP implementations do not provide any indication that the bind is in fact anonymous. GroupWise relies on the success or failure of a bind to determine whether a users username and password is authentic when LDAP authentication is being used [if you put LDAP trace on you will see that blank password become anonymous binds]. The problem is in the RFC, not GroupWise. Once we realized that RFC had the hole, we made a change in the POA. This problem only came to our attention about 2 weeks ago so it takes time for information to get out. Remaining question: How come the Padlock fix was so heavily advertised (read: spammed) and this major hole was open? Why didn't the FTF make a bigger deal of it?
This archive was generated by hypermail 2b30 : Wed Feb 20 2002 - 19:01:59 PST