Interesting prob with CUPS printserver and Windows users

[Ric_]

As you are all aware, I have implemented a PyKota print server and it's really good with only minimal tweaks required at the moment to speed up printing on specific printers - a note on this will be added to my HOWTO.

 

Anyway... it seems that a random selection of users (staff and pupils) cannot connect to the printers. As far as I can see, there are no differences between any of the working and non-working users and it doesn't look like profile problems because enterring different credentials when adding a printer manually works fine.

 

This is currently VERY bad and help is needed QUICK!!!

 

It's got to be permissions or something but, like I said, I cannot see a difference between those users that work and do not work. I have also checked that the Linux box understands the non-working users using 'wbinfo -i | grep '

[CyberNerd]

a couple of things to check might be

UserPrincipleName == sAMAccountName and differences with primary groups

[Ric_]

@CyberNerd: I have checked all the properties and ther doesn't seem to be any discrepencies. I have made a copy of a user that does not work and this copied user also does not map the printers.

 

Is there any way to generate a report outlining the differences between two accounts?

[Geoff]

Dump the user info via LDAP and diff the results?

[Ric_]

I have used LDAP Browser to view two users side by side. One of these users can connect to printers the other cannot. Both users are staff users and were created at the same time.

 

The only differences between the two usrs are what you would expect - names, etc.

 

I am really struggling here and desperately need to find a solution. Any ideas people?

[DMcCoy]

Do you have more than 1000 user objects in AD? Does the linux box query all user objects or request one? You might need to increase your ADs maximum search results, I increased mine to 1500 for my mac server to return ldap user searches correctly (if returning all users then some were missing).

[DMcCoy]

Move a non working user to a seperate OU and only search that OU and see if it works.

[Ric_]

How do I change the maximum search results? I definately do have more than 1000 user objects.

[CyberNerd]

http://support.microsoft.com/default.aspx?scid=kb;en-us;315071&sd=tech

 

I'm not 100% sure this is the problem, certainly I've seen similar symptoms with LDAP queries, but AFIK winbind doesn't use ldap ??

[Geoff]

It does not. It uses native Active Directory RPC calls.

[CyberNerd]

Are you running nscd ?

It is known to cause problems with winbind

http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/winbind.html#id385581

[Geoff]

Good catch, I'd forgotten about that.

[Ric_]

@CyberNerd: Unfortunately, that was not the problem

 

Upon some further inspection though, it appears that Winbind is failing to get the user info for these users. For example, a working account gives:

debian-02:/etc/init.d# wbinfo --user-info=ipa

ipa:*:11221:10000:Mr I Patel:/home/BAINES/ipa:/bin/false

While a non-working account (in the same OU and with the same group membership, etc.) gives:

debian-02:/etc/init.d# wbinfo --user-info=kwx

Could not get info for user kwx

 

Winbind knows that the user exists mind:

debian-02:/etc/init.d# wbinfo -u | grep kwx

kwx

[Geoff]

turn the debugging up and query the user again.

[Ric_]

OK... tried playng with the debug level and I think that the relevant bits are these:

[ 0]: lookupname Unix User log file = /var/log/samba/log.%mroot

[2007/04/19 12:55:00, 5] nsswitch/winbindd_async.c:lookupname_recv(641)

lookup_name returned an error

...

[2007/04/19 12:55:01, 5] nsswitch/winbindd_async.c:idmap_sid2uid_recv(232)

sid2uid returned an error

...

[2007/04/19 12:55:01, 5] nsswitch/winbindd_async.c:sid2uid_alloc_recv(1228)

Could not allocate uid

[2007/04/19 12:55:01, 5] nsswitch/winbindd_user.c:getpwsid_sid2uid_recv(264)

Could not query user's BAINES\copied uid

 

[2007/04/19 13:00:48, 0] tdb/tdbutil.c:tdb_log(783)

tdb(/var/lib/samba/winbindd_idmap.tdb): rec_read bad magic 0x42424242 at offset=249672

[Geoff]

[2007/04/19 13:00:48, 0] tdb/tdbutil.c:tdb_log(783)

tdb(/var/lib/samba/winbindd_idmap.tdb): rec_read bad magic 0x42424242 at offset=249672

 

Ah, the TDB is corrupted. Do you have a backup of the file from before you had these problems? If you do then stop winbind and restore it.

 

If you don't then there's not much you can do but remove the TDB and restart winbindd. Winbindd will then generate a fresh one. This means that all winbindd SID<->uid/gid mappings will be reset to defaults and any winbind local users/groups will be lost.

[Ric_]

@Geoff: Sinc I don't know if this ever worked properly... no backup exists. Looks like I will have to re-create it... shouldn't be a problem though.

[Ric_]

Sweet!!! It's worked!!!

 

Thanks guys for all your help!