Buchan,
I rather fear that it is a problem with the printer, I had to pick at
the settings one by one as there was no decent explanation of what each
field was supposed to do, I had to compare each setting with what the
LDAP log was telling me and then formulate my view of what the setting
was about! I expect somewhere I have got something wrong, but I will
never know as Konica washed their hands of it claiming Opensource woes!
I came up with what I thought the printer should do (I may be wrong!),
but if anyone would like a poke at it, heres the email I sent to them :
I have completed some extensive testing with the LDAP functionality of
your printer software and have come to some conclusions about the
suitability of this software for the purpose it was intended.
OK I have followed the manual exactly, it's wrong, page 5-57 shows that
the username is entered, but this gives an invalid dn in the log file,
which demonstrates that this is incorrect. Here's the log entries :
Jun 13 09:34:18 lowestoft slapd[31250]: conn=6 fd=22 ACCEPT from
IP=128.40.159.32:1309 (IP=128.40.159.4:389)
Jun 13 09:34:18 lowestoft slapd[31250]: conn=6 op=0 BIND dn="" method=128
Jun 13 09:34:18 lowestoft slapd[31250]: conn=6 op=0 RESULT tag=97 err=0
text=
Jun 13 09:34:18 lowestoft slapd[31250]: conn=6 op=1 SRCH base="" scope=0
deref=3 filter="(objectClass=*)"
Jun 13 09:34:18 lowestoft slapd[31250]: conn=6 op=1 SRCH
attr=supportedSASLMechanisms supportedLDAPVersion supportedVersion
Jun 13 09:34:18 lowestoft slapd[31250]: conn=6 op=1 SEARCH RESULT
tag=101 err=0 nentries=1 text=
Jun 13 09:34:18 lowestoft slapd[31250]: bind: invalid dn (nssldap)
Jun 13 09:34:18 lowestoft slapd[31250]: conn=6 op=2 RESULT tag=97 err=34
text=invalid DN
Jun 13 09:34:18 lowestoft slapd[31250]: conn=6 op=3 UNBIND
Jun 13 09:34:18 lowestoft slapd[31250]: conn=6 fd=22 closed
Jun 13 09:34:18 lowestoft slapd[31250]: connection_read(22): no connection!
When corrected with the full dn (Ldap username), then Check Connection
is OK and gives this in the LDAP log;
Jun 13 09:30:38 lowestoft slapd[30506]: conn=1586 fd=18 ACCEPT from
IP=128.40.159.32:1307 (IP=128.40.159.4:389)
Jun 13 09:30:38 lowestoft slapd[30506]: conn=1586 op=0 BIND dn="" method=128
Jun 13 09:30:38 lowestoft slapd[30506]: conn=1586 op=0 RESULT tag=97
err=0 text=
Jun 13 09:30:38 lowestoft slapd[30506]: conn=1586 op=1 SRCH base=""
scope=0 deref=3 filter="(objectClass=*)"
Jun 13 09:30:38 lowestoft slapd[30506]: conn=1586 op=1 SRCH
attr=supportedSASLMechanisms supportedLDAPVersion supportedVersion
Jun 13 09:30:38 lowestoft slapd[30506]: conn=1586 op=1 SEARCH RESULT
tag=101 err=0 nentries=1 text=
Jun 13 09:30:38 lowestoft slapd[30506]: conn=1586 op=2 BIND
dn="cn=nssldap,ou=DSA,dc=adastral,dc=ucl,dc=ac,dc=uk" method=128
Jun 13 09:30:38 lowestoft slapd[30506]: conn=1586 op=2 BIND
dn="cn=nssldap,ou=DSA,dc=adastral,dc=ucl,dc=ac,dc=uk" mech=SIMPLE ssf=0
Jun 13 09:30:38 lowestoft slapd[30506]: conn=1586 op=2 RESULT tag=97
err=0 text=
Jun 13 09:30:38 lowestoft slapd[30506]: conn=1586 op=3 UNBIND
Jun 13 09:30:38 lowestoft slapd[30506]: conn=1586 fd=18 closed
However when logging in as a valid user, with "Use Settings" set on,
then the printer tries a login with the user dn and not the dn set in
the settings, this is clearly wrong. Heres the log output for this;
Jun 13 09:31:30 lowestoft slapd[30506]: conn=1587 fd=18 ACCEPT from
IP=128.40.159.32:1308 (IP=128.40.159.4:389)
Jun 13 09:31:30 lowestoft slapd[30506]: conn=1587 op=0 BIND dn="" method=128
Jun 13 09:31:30 lowestoft slapd[30506]: conn=1587 op=0 RESULT tag=97
err=0 text=
Jun 13 09:31:30 lowestoft slapd[30506]: conn=1587 op=1 SRCH base=""
scope=0 deref=3 filter="(objectClass=*)"
Jun 13 09:31:30 lowestoft slapd[30506]: conn=1587 op=1 SRCH
attr=supportedSASLMechanisms supportedLDAPVersion supportedVersion
Jun 13 09:31:30 lowestoft slapd[30506]: conn=1587 op=1 SEARCH RESULT
tag=101 err=0 nentries=1 text=
Jun 13 09:31:30 lowestoft slapd[30506]: bind: invalid dn (neilmarj)
Jun 13 09:31:30 lowestoft slapd[30506]: conn=1587 op=2 RESULT tag=97
err=34 text=invalid DN
Jun 13 09:31:30 lowestoft slapd[30506]: conn=1587 op=3 UNBIND
Jun 13 09:31:30 lowestoft slapd[30506]: conn=1587 fd=18 closed
Jun 13 09:31:30 lowestoft slapd[30506]: connection_read(18): no connection!
If you use a user name with the full dn of the user ie
uid=user1,ou=People,dc=adastral,dc=ucl,dc=ac,dc=uk, then the login
works, however it still does not use the correct user to bind to LDAP as
set on page 6 of the ldap settings, but binds as the user, heres the log:
conn=34 fd=36 ACCEPT from IP=128.40.159.32:1313 (IP=128.40.159.4:389)
Jun 13 09:46:09 lowestoft slapd[31250]: conn=34 op=0 BIND dn="" method=128
Jun 13 09:46:09 lowestoft slapd[31250]: conn=34 op=0 RESULT tag=97 err=0
text=
Jun 13 09:46:09 lowestoft slapd[31250]: conn=34 op=1 SRCH base=""
scope=0 deref=3 filter="(objectClass=*)"
Jun 13 09:46:09 lowestoft slapd[31250]: conn=34 op=1 SRCH
attr=supportedSASLMechanisms supportedLDAPVersion supportedVersion
Jun 13 09:46:09 lowestoft slapd[31250]: conn=34 op=1 SEARCH RESULT
tag=101 err=0 nentries=1 text=
Jun 13 09:46:09 lowestoft slapd[31250]: conn=34 op=2 BIND
dn="uid=user1,ou=People,dc=adastral,dc=ucl,dc=ac,dc=uk" method=128
Jun 13 09:46:09 lowestoft slapd[31250]: conn=34 op=2 BIND
dn="uid=user1,ou=People,dc=adastral,dc=ucl,dc=ac,dc=uk" mech=SIMPLE ssf=0
Jun 13 09:46:09 lowestoft slapd[31250]: conn=34 op=2 RESULT tag=97 err=0
text=
Jun 13 09:46:09 lowestoft slapd[31250]: conn=34 op=3 SRCH
base="uid=user1,ou=People,dc=adastral,dc=ucl,dc=ac,dc=uk" scope=2
deref=3
filter="(&(&(objectClass=*))(|(mail=*)(facsimileTelephoneNumber=*)))"
Jun 13 09:46:09 lowestoft slapd[31250]: conn=34 op=3 SRCH attr=cn mail l
telephoneNumber facsimileTelephoneNumber o ou givenName sn department
company companyname homeDirectory
Jun 13 09:46:09 lowestoft slapd[31250]: conn=34 op=3 SEARCH RESULT
tag=101 err=0 nentries=1 text=
Jun 13 09:46:09 lowestoft slapd[31250]: conn=34 op=4 UNBIND
Jun 13 09:46:09 lowestoft slapd[31250]: conn=34 fd=36 closed
The user is then appended to the user list so can be selected so that
the user no longer has to type in the long dn.
This "feature" is also clearly wrong and suggests that the search that
is set under Security -> External server Registration is ignored during
login, the search base being set to ou=People, dc=adastral, dc=ucl,
dc=ac, dc=uk and the search attribute being set to uid. With this set it
would be normal for an LDAP device to search using uid="typed in
username",ou=People, dc=adastral, dc=ucl, dc=ac, dc=uk
With this setup it is impractical to "load" the user database with there
full dn, or expect any user to type this in for there first login and it
would require IT Support to know each users password prior to a manual load.
It also expects the user to type in their full dn within their printer
driver to be able to get to their boxes and restricted services such as
colour printing. Again this is over complicated for standard users and
would need to be individually set by IT Support for each user.
I would class this as a serious bug in the software, the expected
functionality given the printer settings would be :
1. User logs in using short name ie user1, and with their LDAP stored
password.
2. Printer construct search string of uid=user1 and uses ou=People,
dc=adastral, dc=ucl, dc=ac, dc=uk as a search base.
3. Printer logs into LDAP with the dn of
cn=nssldap,ou=DSA,dc=adastral,dc=ucl,dc=ac,dc=uk, (set page 6 of
settings) and performs search for the uid and checks password, once
found and if password OK does a second search of LDAP for email address
etc... (or if the engineers are good this can all be performed in one
search)
4. Printer populates user list with short username (actually thats a
security flaw it should populate the user list with the name of user,
information that can be searched in LDAP (givenName and SN or
displayName etc..) The printer should link the real name of the user to
the username in the background and never show the username itself.
Next time the user accesses the printer they can select there real name
from the list and login with their network password, done simple!
The printer driver should also be able to access the constructed full dn
of the user, thus enabling a normal user to just enter their standard
short username and password.
Of course I may have got things all wrong!
Thanks,
Neil.
Buchan Milne wrote:
On Monday 30 June 2008 12:25:21 Neil Marjoram wrote:
> I would really like to here the groups comments on this email I received
> from KonicaMinolta, it refers to the Bizhub C451 printer, but I
> suspect it applies to the whole range. On purchase of the printer I was
> told it supports LDAP, and as you may expect this response somewhat
> annoys me!
>
> quote "Thank you for your observations,
>
> We have now received a reply from our colleagues in Germany and they
> have confirmed the following concerning LDAP compatibility on
> KonicaMinolta machines:
>
> "In a Windows environment, it will work fine, but as soon as Open Source
> is used, it may fail.
[...]
> All Windows based LDAP V3 compatible Servers are supported.
So OpenLDAP on Windows should work? And Sun JES LDAP on Windows ? And Netscape
Directory Server? And eDirectory ?
Anyway, if you provide more detail on exactly what your original problem was,
maybe it can be resolved.
Regards,
Buchan
--
Neil Marjoram
Systems Manager
Adastral Park Campus
University College London
Ross Building
Adastral Park
Martlesham Heath
Ipswich - Suffolk
IP5 3RE
Tel: 01473 663711
Fax: 01473 635199
Reclaim Your Inbox!
http://www.mozilla.org/products/thunderbird