Topic: Loss of domain login on WinXP Pro

[compsos]

Hi
Problem : WinXP failing the logon with bad username or password. This is after it has been working for sometime. It normally will work for the "regular' user.

Registry edits were done and the system has been a member of domain for reasonable amout of time (months). The requiresecuresignorseal entry is still set to 0.

Even admin is rejected! But from a "local" profile the server can be addressed and accessed with a valid user & password.

So far have "solved" by removing from domain and then rejoing.

We have seen this now on at least a dozen machines.

Has anyone else experienced this and found a better way to solve the problem without the orphaning of existing profiles? I do suspect it to be a XP client
issue rather than server side.

[dave_d]

I had this happen to me on one occassion and I ended up making the following changes ... (on Windoze XP - SP2)

1. Using the Start/Run command, run C:\Windows\System\gpedit.msc

This is the Group Policy editor.  Navigate to Local Computer Policy/Computer Configuration/Administrative Templates/System/User Profiles  and double click on the entry "Do not check for ownership of roaming profiles"  and ENABLE it.

Exit the Group Policy editor.

2. Using the control panel start the Administrative Tools and the start the Local Security Policy application.  Using this make the following settings...

Navigate to Security Settings/Local Policies/Security Options and set the following

Domain Member: Digitally encrypt or sign secure channel data (always)   - DISABLE
Domain Member: Digitally encrypt secure channel data (when possible)   - DISABLE
Domain Member: Digitally sign secure channel data (when possible)   - DISABLE
Domain Member: Require strong (Windows 2000 or later) session key   - DISABLE

3.  I have seen some discussion on the Internet about the "Maximum machine account password age" setting too, but I have never seen a definitive requirement for this with respect to a Linux/Unix domain controller.  I suppose it's something to play with if you start to see a pattern of behaviour with the same time scale.

BTW, I don't fully understand the implications of all these settings, I gleaned the information from various locations on the Internet.  The authors know who they are - thanks!


Hope this helps,

Regards,

Dave

[compsos]

Hi Dave

Will give it a go with this site (now that it is all cleaned up) and see how long it lasts.

I had seen the machine password age but like some other things in gpedit.msc adjusting them seems to have no effect.

Many Thanks

[compsos]

Hi
Might have found something. There is a setting in the gpedit.msc under
"Computer Configuration
Network
Logon
Always wait for the network at computer startup and logon"

Setting this to enabled switches back to Win2K style of logging on and waits for the network instead of using a local cached copy. Suspect local copy maybe corrupted and causing the failure.

Has anyone else tried this?

[dave_d]

That's an interesting one!  This *COULD* be why I've been having trouble lately making changes 'stick'.  For instance, I've currently got a situation where clients are using iPaqs synchronised to their local XP boxes.  On one of the PCs it seems that it doesn't matter how many times I fix the synchronisation problem, as soon as the PC is turned off overnight and restarted then the synchronisation problem returns.  I'll try changing this parameter and see what happens!

Dave

[compsos]

Dave

Just for reference most of the properties are set to disabled only these 2 were enabled
Domain Member: Digitally encrypt secure channel data (when possible)
Domain Member: Digitally sign secure channel data (when possible)

Also all of the can be done in gpedit.msc. Also note gpedit for SP1 & SP2 now have different options. Lots of new ones in SP2.

[dann]

Hi All,

I think I've read every post about people having trouble with XP Pro logging into an SME server set up as a domain controller but I have not seen this one yet unless I missed it.

I just built up a new XP Pro machine from an install CD that installs with SP-2 included. Upgrading from XP Pro SP1 to SP2 has not caused any problems with connecting to the domain controller SME server.

Here is the problem: When user name johnc is used to log into the local machine (johnc.eng2), the rights are set to admininstrator as I want. When johnc logges into the domain (johnc.domain), the rights appear to be set to restricted as defined my MS. I cannot figure out why the rights change depending upon where he is logged into. As far as I know there are no policies on the SME server 6.0.1-01

Anybody go any ideas as to how I can fix this beast? For the time being, I'm going to have the user log into the local machine.

Much thanks,

[compsos]

Dann

Each of those users are different under MS OS. have a look under Documents and Settings. Because the local one existed when logging on to the domain it creates a whole new profile.

A single interface for all users would be great for most small offices/networks.