DLU and Pass-through Authentication
Novell Cool Solutions: Trench
Digg This -
Posted: 2 Mar 2004
Recently we published this Q&A, and have received additional suggestions, and follow-up questions.
Question: We use eDir as our primary directory and authentication. We have Windows NT4/2k workstations. We run application servers eg., Windows 2000 running SQL 2000.
How can we authenticate users to the application servers without them having separate logins? We would like to have pass-through authentication.
We have Dynamic Local User accounts so that any eDir user can login to any workstation.
We have recently created an Active Directory domain that has the user accounts created via DirXML. The problem with this is that for users to login to the domain the workstations have to be members of the domain. When logging in with the Novell Client this creates the Dynamic Local User and this user does not allow pass -through authentication. If we use a policy without Dynamic Local User and select the domain in the Windows tab of the client (once the workstation is a member of the domain) then the pass-through authentication works.
Is there a way to allow pass-through authentication of eDir users to Windows 2000 servers? We would like a method that does not require adding all of our workstations into Active Directory. If we can find another method then we may not need Active Directory (unless Microsoft forces AD to be used in future versions of servers or applications).
If we do need to stay with Active Directory and add workstations, is there an easy way to make the workstation members of the Active Directory domain?
Answer: We checked with the Reverend Ted, and he said, "When it comes to DLU and Domains, one of the longstanding statements from Novell has been: don't use Dynamic Local User if you have a Windows NT domain or AD tree. But indeed, that does create the problem of having to add your workstations to the domain. There's not really any easy way to do this.
"There may be some creative way to create the workstation objects in the domain by adding them to eDirectory (automated through ZENworks automatic workstation import, transported and transformed to the correct object type in the domain by DirXML; and membership settings pushed to the workstation via a ZENworks workstation policy) but it has not been tried (to my knowledge)."
Anyone got any suggestions? Fire when ready.
- William C. Schneider
- Andrew Bridgens
- Darren Eslinger
- Michael Kirby II
- Mark McGee Question
- Jasen L. Webster Question
- Trina C. Johns
- Chris Beckett NEW
- Heiko Friedrich NEW
This script allows you to join the computer to the domain. With some modifications you could probably create a force-run NAL to run this. You may then have issues with the profiles on the PC but the Personality Migration wizard should be able to help you there.
We've used the following command in our imaging scripts - can easily be adapted to work with ZEN.
netdom.exe join %computername% /Domain:MYDOM /UserD:domainuser /PasswordD:domainpwd
Create a user "domainuser" with password "domainpwd" with rights to create workstations.
As our users are local administrators we also use
net localgroup Administrators /ADD "MYDOM\Domain Users"
First, it was never stated why they needed a domain. It may be that there is a way to do what they want without a domain or without AD.
Second, the workstation does not need to be in the domain to connect to servers that are in the domain. You only need the workstation to be in the domain to take advantage of certain features such as GPO's, SMS, single signon, and centralized management to name a few, most of which they have with eDir and ZfD.
Perhaps with some information as to why they think they need the Windows domain or what exactly they need to accomplish we may be able to supply better suggestions. It sounds to me as if they created an AD tree "just because they can" and are therefore taking the more difficult path to get to their destination.[Editor's Note: We'd be glad to add more details, if the questioner cares to supply them.]
Update from Darren: Regardless of whether AD is needed or not, this is an ideal situation for implementing Novell Account Management and/or Novell SecureLogin.Novell Account Management can ease administration headaches with account management on the standalone servers and tie authentication nicely into eDirectory.
Novell SecureLogin can help the users manage all the IDs and passwords that could be required in this kind of environment.
Together, the two solutions would provide a complete end-to-end solution for a multi-platform environment while increasing overall security.
While this requires the purchase of additional Novell products, the TCO would most likely be cheaper than the implementation and maintenance of an AD infrastructure.
We have run into a similar situation. We needed to access data on a Win2k server. In order to do this we need to authenticate to this Win2k box. The way we accomplished this was adding a line to the Novell login script such as:
@net use \\win2kservername\IPC$ /USER:win2kservername\win2kaccountname win2kaccountpassword
- "win2kservername" is the name of the Windows 2000 server you want access to.
- "win2kaccountname" is a local Windows 2000 user account on the Win2kserver.
- "win2kaccountpassword" is the Windows 2000 password for the local account.
This has a drawback, the password to the account is stored in the login script in clear text. A bit of a security issue.
Also, users will see a black DOS box when they login. I have not figured out how to make it run minimized.
Hope this helps.
We are having a similar problem with our setup. We have a few Windows 2003 servers running terminal services for our gradebook attendance program. Our computers and/or users don't have any reason to login or join the domain on their individual workstations. In fact, the main reason why the application is on the terminal servers is because it's the only application we currently have that requires an AD domain to function. We have DirXML to sync our users accounts and passwords from eDir to AD.
The problem is that when the users want to use the gradebook attendance software, they have to login to the domain before they can do so. This allows them to create their own unique profile on the server so they are the only ones that see their printers when installed automatically by terminal services (otherwise you could see EVERYONE's printers and even print to someone else's home printer!).
Any suggestions would be great!!
Can Novell exteNd screen scraping technology provide this type of solution?
Or what about the Single Sign-on product?
Has anyone considered removing Active Directory and setting up eDirectory for Win2k? I haven't had a chance to play with it yet and I'm curious.
The 4.9sp1a client allows for the UPN (User Principle Name -- email@example.com) to be used to look up the user in the domain. If the user name and the password are the same in both eDirectory and AD it should pass through the credentials. You will also want to use DirXML to make sure the passwords are synchronized between the two directories as well so that the users are not prompted when there are password changes.
I would suggest testing the UPN syntax first in AD with the proper Global Catalog configured and make sure it is correct before installing the NW client.
In the client's location profile you can enter the domain syntax "@domain.com" and just enter the user's name and it should pass through.
What I recently discovered is that you can "chain" the GINAs (the authentication mechanism) so that you log into AD first using the MSGINA and this then passes the User ID and password onto the NWGINA for NDS authentication (this works as long as both pairs match!). You need to change a registry key to enable this, have a look at TID 10057160 for a starting point. If and when I get more time, I may knock a Cool Solution together.
Here is one that isn't pretty but does the trick in certain situations.
If you have the eDir and ADS accounts synched via DirXML and passwordsync, there is a fairly simple solution to allow a DLU user/workstation to connect to the SQL database, using the "integrated windows authentification." Simply make the SQL server a domain controller.
The client will then try to connect to SQL server. The SQL server sees it is supposed to use the Windows authentication, so it checks for the SID. Because we are not authenticated to the domain, it won't find any. The SQL server will then actually check its local SAM database, asking the connecting workstation for the user name and password.
And here is where the domain controller does its magic. If the SQL server is not a domain controller, the user's credentials will not be in the SAM and authentication fails. If however the SQL server is a domain controller, the 'local' SAM is the ADS store. The server will find the user with the password, because we used DirXML and passwordsync to make sure of that.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com