OPEN CALL: Dynamic Login on Restricted Workstations
Novell Cool Solutions: Tip
By Diana Ortega
Digg This -
Updated: 15 Nov 2007
MK wrote: I am running ZENworks for Desktops 7 SP1 on NetWare 6.5 SP5, created policies and imported all workstation objects ( Windows XP SP2 and Novell client 4.91 SP3). The problem I am experiencing is that Dynamic login DOES NOT work as long as ENABLE LOGIN RESTRICTION is checked.
I want to restrict DLU access to certain workstations. What can I do to solve this issue? We are not using Middle-Tier server.
OPEN CALL: Anyone have any ideas for MK? Let us know and we'll give you Novell Rewards points for every suggestion we post here.
- David Frey
- James Rudd
- Stefan Ensing
- Robert Parlett
- John Snider
- Christopher Farkas
- David Szott
- Pat O'Reilly
- Barry Cavanaugh Updated
- Reynold Auckenthaler
- Ben van der Linden
With ZfD 3 there was a "Restrict Login" policy (the Restrict Login policy was removed with ZfD4, so ZfD3 extensions will be necessary). I am supporting an environment that was upgraded from ZfD3 to 4 to 7 so those schema extensions are still there, and I have used such a policy to restrict login for certain workstations. In the ZfD7 environment described, one way to accomplish this would be to install the relevant ZfD3 schema extensions and the appropriate C1 snap-ins and use this policy (which in my opinion should have never been abandoned <clears throat>). It still works as long as the proper extensions and snap-ins are there. As a precaution it wouldn't hurt to re-apply the ZfD7 extensions afterward just in case. As always, test in a lab environment prior to moving into production.
Email me for specific instructions: dfreyATgenesys-computer.com
An easy way would be to apply the following registry patch either manually to machines or deploy to selected PCs using a ZENworks Application Object.
REGEDIT4 [HKEY_LOCAL_MACHINE\SOFTWARE\Novell\Workstation Manager] "DLUAllowed"=dword:00000000
My guess is that it is just not configured properly. You need to specify the workstations that are included for this to work -- if you only check the box Login Restrictions it will fail. See screenshot below for the proper way:
If I understand the problem correctly, you want to exclude DLU on most of your machines for this particular policy package, and make exceptions for just a few. In that case you need to add the workstation container to the "Included workstations" column in the login restiction policy. Make sure that the workstations you are allowing the DLU Policy users to login to are added to the "Excluded workstations column." It may seem counter-intuitve, but that's how it works.
I'm a desktop administrator for a public school district in Michigan. We have the same software configuration that you do. We use DLU for all student and teacher accounts throughout our school district. At our elementaries, students use a generic account based upon their grade level and building, but at the High School, and Middle School level, they use their own account. Because we have multiple buildings with multiple servers, we decided that it would be a good Idea to have individual policies (ie DLU) for each building.
Not long after we implemented this we started noticing the generic accounts were being used at our High School and Middle School. To fix this, we enabled the "ENABLE LOGIN RESTRICTION" and included all the workstations for the building that the policy was at. However, I have not been able to exclude workstations from the DLU - every time I add a workstation to the exclude list, it prevents even the included machines from logging in. If you leave the excluded empty, you will only be able to DLU into the computers that are in the included section.
The only other thing that I noticed is that you didn't mention "Restrict Unregistered Workstations" We have this checked in our environment.
It's a brute force method, but you can enable DLU and let the users you "want" to log onto those special workstations do so, then disable DLU.
That way, other users cannot log into the workstation, unless they have a previous account.
If you need to get someone onto that box afterwards, you can enable DLU (to create their own) or just have the administrator go and manually creates the user's account for them.
Unless I misunderstand this person's scenario, we have the same setup: WinXP SP2 client 4.91 SP3 with ZENworks for Desktops 7 SP1. We used to have NetWare 6.5 SP5 (NetWare kernel, not Linux), ZEN 6.5 SP1, but have just recently moved to NetWare 6.5 SP6 (installed from scratch, loaded eDir from scratch--i.e., we didn't upgrade the old servers) and ZEN 7 SP1 (imported workstations from scratch--i.e., didn't upgrade). We do not use a middle tier server. DLU worked in both setups.
We also restrict DLU on certain workstations. I just tested it again on a newly imaged PC, and it works as expected. We set up the policy with DLU enabled in the XP (not "general") area. We enable login restrictions. All our workstations are in a particular OU set up just for them, and we put that OU in the "include" list on the right side, and then we add the workstations we don't want DLU to take place on in the "exclude" list on the left side. We associate this policy to all our users (not to an OU).
We have two separate policies, one for limited users and one for administrators. Our DLU users are normally Windows limited users. When they need to be a Windows administrator for installing something, we add them to the other policy (takes them out of the current policy), and have them log in and do their thing. When done, we add them back to the "limited" policy and have them log out and log in to revert to being a limited user.
For users with workstations in the excluded list, we manually created their Windows account. They don't want other users to be able to DLU into their Windows machine, and the DLU login restrictions accomplish that.
I'm not sure what we have different from this person's setup, but ours works. At first we just added the excluded workstations. DLU didn't work until we added the workstations' OU to the included list. Also, I'm not sure what the problem was, but we did have some problems when we associated the policy to the OU our users are in, and we got things working by associating the policy directly to the users instead.
We have a similar setup to MK, we had the same problem also. We installed the ZDM7SP1HP6 patch and our problem seems to be resolved for most of our admins. We made some changes to one of our desktop images which is still preventing this from working for one group. It seems we will have to rebuild that image and test this feature regularly during the image build to see where it stops working. Hopefully we can then go back and fix whatever is broke on the machines already rolled out for that group. If you use a base image, it might be an idea to apply the policy to a machine with that on it, if that works then add on from there and test it as you go. Good luck with it.
Freshly Updated. I work in a county public school system and have thought about ways to control logins for select stations.
To me flexibility is the key, as these situations can be quite different from one another. An easy method is to use a AutoIT script and compare the login username to the approved list either hard coded, in a text file or pulled from the registry. If the name is not on the list, log the user right back out. Run from the "run" key or as a service (more is needed than what I am showing, and I have successfully done this). This could almost be as simple as:
If (@Username <> "ValidUsername") or (@Username <> "Administrator") Then Shutdown (0) Exit
Note: Shutdown (0) means to log off the user. Or you could get fancier:
$ValidUsernames="Administrator" $ValidUsernames="Ray" $ValidUsernames="Jill" $ValidUsernames="Toni" $ValidGroup=?Drafting? If $CmdLine > 0 Then $LoginCurrentGroup = $CmdLine EndIf For $i = 0 to 3 Step 1 If @Username <> $ValidUsernames[$i] Then $blnValidUser = True Next If $LoginCurrentGroup = $ValidGroup Then $blnValidGroup = True If Not ($blnValidUser or $blnValidGroup) then Shutdown (0) Exit
I have wondered if Novell sets an environment variable with the group name(s) of the user but it could be written to the registry or to a file or as a param through the login script. Example login script:
If MEMBER OF ?my1stgroup" Then # C:\Program Files\MYAPPS\MY_AUTOIT_SCRIPT.EXE /my1stgroup Else If MEMBER OF ?my2ndgroup" Then # C:\Program Files\MYAPPS\MY_AUTOIT_SCRIPT.EXE /my2ndgroup Else # C:\Program Files\MYAPPS\MY_AUTOIT_SCRIPT.EXE /everyoneelse EndIf EndIf
It would be nice if such control would be handled before the login is initiated, but then again you could easily gain customized features if you roll your own. For instance you could log the user / group logins as at this point the improper login attempt has been made with the correct password! This may be a security concern that you will want to be alerted to.
We have a implementation of ZENworks DLU functionality where DLU users can only login to specific workstations and it works fine. This doesn't work when Windows autoadminlogon is enabled of the workstation.
We had the same problem too - DLU on all the xp tab. But we included all workstations with the include tab, except those users may not login to.
The workstations people may not login to were added to the restricted workstations. That resolved the problem.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com