Discussion Locked

Change password on standalone W2K server

0 helpful
12 replies
Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

Hi,

Our users are logging to our main Win2K AD domain (AD Domain). However, some users require to have a permanent drive mapping to a file share on an standalone Win2K server (Svr B).

When we started, we set the same password for both the AD domain and the standalone file svr for the users, so that they don't need to key in password for the drive mapping to Svr B every logons.

However, at every 90 days when AD Domain forces all users to change password, they'll be prompted to change only the password for the AD Domain, but not Svr B. So, these 2 passwords will be different and the users will not be able to logon to Svr B immediately. Also, since the users have no means to change the password themselves, I've got to get them to go to the server console to change password on Svr B's console.

Appreciate any suggestion to how we can force both AD Domain and Svr B to change password together, every 90 days?

If not, is there any means for users to change password for Svr B, in a GUI manner - 3 fields interface (old pw, new pw & new pw retype)?

Appreciate all help given.
Thks.

12 replies

by ariston

Is there a reason why your standalone server is not a member of your active directory network? If you add the server as a member, then the authentication should pass through from AD to the 2k server whenever the passwords change.

One option would be to create a VBScript file that will talk to the server and change the password for them, however, they would need to have administrative rights on the server in order for that to work.

Honestly, your best bet would be to add the server to your Active Directory infrastructure so any AD password changes would apply to the users on the other server.

Hope that helps!

Ariston Collander
ariston@coxcomputer.com

by everyoneall

The standalone file server is not being managed by the main IT admin team (ie. admin password only held by the user dept directly), due to the sensitive information stored on that server.

Thks.

by lcampbell

Could you not just select the checkbox on the users that passwords never expire on the stand alone??
If it isn't part of AD then it shouldn't follow any of the domain policies regarding password change anyway.

by lcampbell

Then just set the local policy at the STand alone to a 90 password expiry. If you set it according the your domain policy, it should follow insync from the stand alone.

by lcampbell

Most logical way would be to bring standalone server into the AD as a DC in a child domain. You will retain security (highly sensitive data) and departmental managment (delegation) AND you will be able to set different security policies on the child domain.

by everyoneall

The objective is we'll no have any access to the dept server. Joining as a sub-domain, would allow the parent domain administrator to have access to the dept server in the child domain.

by lcampbell

I'm sorry, maybe I'm missing something with this one but, it seems to me that if you can create users on the stand alone, you would be able to manipulate the accounts at least to set the password expiry to 90 days on them.
There is no connectivity issues or DNS issues to deal with as it's not part of AD. It's a simple local policy setting on a per user basis.

by everyoneall

Thks for repeated attempts.

Our IT side does NOT have any admin access at all, not even for account creation. Accs are created with the user dept logging in the standalone server admin acc for IT side.

Appreciate your help but let's come back to my actual qn, rather than going thru' the need, the reason, etc. Thanks.

by lcampbell

Sorry I haven't been much help to you. This situation is just confusing me even though the logistics of it are so simple.
Your AD will not prompt users to change the stand alone password. For obvious reasons.
It only makes sense the the users must go to SrvB console to change password as they are only local user accounts, not networked.

This discussion is closed to new replies.