Michael,

The whole issue revolves around how the printer searches, and then what fields it uses for the username. The printer can be used by the user via ldap, however when the user first logs in they must enter the full dn of there user id, most of them have never heard of it! Auto population becomes impossible without changing everyones password. Further more the second time the user is prompted to search a complete list of everyones uid until they find theirs - not a pretty sight. It does successfully extract the email address for scanning! The third problem is the driver, we restrict colour printing, so the user must send the login details via their print driver, again this means entering the whole string not just the username. This is all too complicated for the average user, and I have many professors, so near on impossible!!

What I'd really like to know is whether the remarks Konica have made about RFC's etc are correct for openldap, before I start a little battle!

Many thanks,

Neil.

Michael Ströder wrote:

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!

Ah well, commercial support...

But you also did not elaborate on what *your* problem is.

...

"Referral Settings"

Is your problem that the printer does not chase referrals correctly? Then I'd recommend to work around this problem by using slapo-chain.

Ciao, Michael.

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