login failing on machines that used to authenticate fine

We have five Macs running 10.5.8, bound to AD & OD, where login fails with a ‘shake’ or error message `unable to login ... at this time`. 11 other Macs in the same room, configured similarly, where login succeeds as normal. The domain can be pinged successfully from each. In Directory Utility > Directory Servers the domain academic.greenhead.ac.uk is marked `green` but marked `This server is not in your authentication search policy` (the OD server is also marked green with no error message - OK). Search Policy tab – it is present - remove and re-add - no change. 1) One suggestion on: http://discussions.apple.com/thread.jspa?messageID=8006003 which worked for some, but not others: "Apple have enabled LDAP signing and encrypting in 10.5.3. If this isn`t enabled in your AD this will cause problems. The solution is either to enable this for your AD, or disable encryption and/or packet signing (we had to do both) on the Macs. The second solution may be easier:- Make sure the machine is not bound to the AD (no red gems etc.) then... In terminal:- dsconfigad -packetsign disable dsconfigad -packetencrypt disable Reboot and rebind." 2) Another suggestion at http://openradar.appspot.com/6541409: `Open (edit) the Active Directory entry in the Services panel. Enable "Allow authentication from any domain in the forest" Close this panel and go to the "Search Policy" panel. You should now find "/Active Directory/All Domains" in the list of domains which can be added. Add it Return to the services panel and disable "Allow authentication from any domain in the forest".` This article seems to imply that this doesn`t affect logins? Tried both 1 & 2 (but not enabling LDAP signing, the disabling packet signing & encrypting) - still no login. Rebinding each Mac to AD has fixed for one, but not the other 4. Check Microsoft DNS - all have correct A & ptr records except one which didn`t have an A record – now corrected. Check time servers and correct where necessary - restart machines - still same problem. Strangely and perhaps significantly, AD domain administrators can login to the machines OK. Any ideas?