Article

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.

Suggestions

• David Frey
• James Rudd
• Stefan Ensing
• Robert Parlett
• John Snider
• Christopher Farkas
• David Szott
• Pat O'Reilly
• Barry Cavanaugh
• Reynold Auckenthaler New
• Ben van der Linden New

David Frey

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

James Rudd

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

Stefan Ensing

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:

Robert Parlett

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.

John Snider

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.

Christopher Farkas

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.

David Szott

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.

Pat O'Reilly

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.

Barry Cavanaugh

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 and 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. This would be as simple as

If @Username <> "MyAllowedUsername" or @Username <> "Administrator" Then Shutdown (0)
Exit

or

$MyUsernames[0]="Administrator"
$MyUsernames[1]="Ray"
$MyUsernames[2]="Jill"
$MyUsernames[3]="Toni"
For $i = 0 to 3 Step 1
    If @Username <> $MyUsernames[$i] Then Shutdown (0)
Next
Exit

Shutdown (0) means to logoff the user.

It would also be nice to check the user group against an acceptable list. The current user's group(s) can be obtain via the Novell login script. I have wondered if Novell sets an environment variable with this information but it could be written to the registry or a file if not, then compared to what is allowed and then again force ably eject log them out.

It would be nice if such control would be handled before the login is initiated, but then again you could easily gain all sorts of customized features if you roll your own.

Reynold Auckenthaler

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.

Ben van der Linden

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.