Strange problem with local permissions on WinXP using a Samba PDC with LDAP backend
I've an unusual problem on my local network. Several internal users whose accounts have been created recently can not access SSL websites.
A quick explanation of the setup would be useful:
- Windows XP Pro Workstations
- Debian Linux Samba Domain controller with an OpenLDAP backend
- Several different custom groups controlling network file access
- All client machines are identical in hardware and software
When logged in as one of the affected users, Internet Explorer prints a standard "Cannot find server or DNS error" message when one tries to visit ANY SSL website, whether it be local or external.
However, if that user is added to the "Domain Admins" group in LDAP, everything works fine! This rules out any proxy/networking problems.
I've created a new user on the domain, using the default profile and in the default group, to work with in testing. I've logged this user onto many machines but to no avail. If I add this user to all other internal groups, it still doesn't have access to SSL.
After much testing, I've derived that the cause of the problem is that the user has restricted access to the local hard drive. IE can't save/read certificates and SSL doesn't work.
This is reinforced by two tests:
1. If I install Firefox, using exactly the same proxy settings as IE, everything works fine. (stores files elsewhere)
2. I can't view any certificates locally, but I can as a 'privelaged' user (It seems I can't post a link to another site yet, for a screenshot go to office dot blits dot com dot au slash cert.jpg)
This has me scun as there are other users on the system who have EXACTLY the same group memberships but can access SSL sites fine.
I realise that this is a sore topic as it has so much to do with Windows, except I don't seem to be getting any support from the Microsoft world because I'm using Linux to drive things.
Any input would be greatly appreciated!
Thanks in advance
I figured I might reply to my own post with the solution.
My problem was an invalid security descriptor on the user's registry file (ntuser.dat).
Upon login, the user's registry was loaded, but they couldn't access parts of it, causing various things to fail.
The problem was rectified using SetACL (on sf.net) over the network using the following command on a machine with admin access to the workstation...
SetACL.exe -on "\\machine_name\users\S-1-5-21-4132040453-3518729020-110902423-8162" -ot reg -actn ace -ace "n:DOMAIN.COM\username;p:full"
The long string being the SID of the user, obtained from the LDAP database.
I really hope this helps someone in the future as I've spent weeks trying to work this out!!!
Now I'm onto the task of making a better default_profile as the cause of this was that the default_profile has existing security descriptors referring to a non-existant user.
I'll post my findings.
i was facing like that problem...
|All times are GMT -5. The time now is 04:29 AM.|