Difference between revisions of "Client Authentication:Windows"
m (moved Windows Integration to Client Authentication:Windows: Comparability with other page names) |
m (categorisation) |
||
Line 50: | Line 50: | ||
{{Incomplete}} | {{Incomplete}} | ||
---- | ---- | ||
− | <noinclude>[[Category:Howto]]</noinclude> | + | <noinclude>[[Category:Howto]] |
+ | [[Category:Administration]]</noinclude> |
Latest revision as of 20:37, 11 May 2010
Microsoft Windows integration with SMEserver
Goal
Provide hints and tips to make life a bit easier in mixed environments.
As suggested in this forum thread: http://forums.contribs.org/index.php?topic=39396.0
If you have exactly the same usernames and passwords in both clients and server, users only have to log in once (to Windows) to have direct access to shared recources on the server.
Domain Admins group
By default, SME Server allocates the "admin" user as the sole Domain Administrator. However, in larger environments it is often useful to have a group of users who can administer Windows workstations.
To make a group of users Domain Administrators, simply name the group as normal and write "Domain Admins" as the description. When users who are members of this group next log in to a Windows workstation that is joined to the SME Server domain, they will have Local Administrator rights automatically.
How to change PDC from Windows 2003 to SME Server.
From http://forums.contribs.org/index.php?topic=40228.new;topicseen Q: Is there any way in which i can do this without having to backup all the XP PC's and re-adding the PC's to the new Domain and then restoring all the files ?
A: The Microsoft "Active Directory Migration Tool" is supposed to do all of this automatically -- but always looks like it will take 30 - 40 hours of effort to setup, debug, and test prior to hitting the "go" button...
I move PC's from one domain to another as follows:
- Setup identical usernames on the new domain controller
- Add the computer to the new domain
- Login to the new domain NOT as the user who uses this computer (but with local administrative rights on the workstation).
It is important to NOT login as the intended user until after the following step, or you will create a new profile directory named for the new domain, and you'll have to use the "variation" listed below.
Sometimes (if the old profile included auto-start programs that don't close on logout), you may need to reboot the computer, making sure that the first login after reboot is to a user account that is NOT the intended user for the computer in order to be able to rename the intended user's profile.
- Rename the user's profile c:\documents and settings\username ==> c:\documents and settings\username.old
- logout
- login as the intended user (re-creating "c:\documents and settings\username")
- logout
- login as another user with local admin rights (the same user used above, for example)
- rename the new userprofile c:\documents and settings\username ==> c:\documents and settings\username.new
- rename the old user profile c:\documents and settings\username.old ==> c:\documents and settings\username
- Change the ownership of the old profile to be the new user (or give the new user local administrative rights on the workstation)
- logout
- login as the new user - s/he should now have the exact same environment s/he had on the Windows server.
Variation - can't use the old username, or old profile name is incorrect, or you've already created a new profile name for the intended user
If the old profile name is "username.domainname", or if you're trying to change the username but keep the settings from the old system:
- download and install the Windows 2003 Resource Kit
- follow the above procedure, ending up with the old profile named correctly for the new login credentials
- use "linkd.exe" (from the W2k3 resource kit) to create a "link" to the new profile with the exact name of the old profile, in case any of the registry settings include a hard-coded path to the old profile directory name.
(note: you don't need to install the entire resource kit on each workstation, you only need to put "linkd.exe" somewhere where you can get to it from each system - either in c:\windows on each system, or in a network share, for example)