|
Dynamic Network Rights
According to Novell, they are still working on the ability to
assign dynamic rights to applications so that a user cannot access
those rights outside of that application. In other words, when they
launch the object they have the rights to perform the actions
related to the object and when they exit the app, they no longer
have those rights. Through the use of ZENworks and a few nifty tools
from the NT Resource kit, I have put that ability to work today. I
have developed 3 separate methods in which this can be done today.
Method 1 - The SU Utility
Limitations – Requires NT workstation and NT Resource Kit
The SU utility is a utility from the NT Resource Kit supplement
4. This will install a service on an NT box which will launch a
application with the rights of a specified user. This user must be a
valid NT user. If you also wish to access Netware resources, you
need to have an NDS user defined within your current context with
the same name and PWD as the NT user.
1) Install the SU utility on the NT box. (This can be done via a
push with Zenworks)
2)Create a Dummy NT user on the NT DOMAIN – assign any necessary
rights
3)Create a Dummy NW user (in same context) with same name and PWD
as the NT user – assign any necessary rights
4)Create APP in NDS
COMMAND LINE=CMD.EXE
Environment = /cecho pwd|f:\su\su.exe userid "notepad.exe"
ms_domain
4a)Create APP in NDS
COMMAND LINE=f:\su\su.exe
Environment = userid "notepad.exe" <f:\passwds\userid.txt
Set app impersonation to "Unsecure System User"
The final line calls the SU utility with parameters of the user
ID, the application to be run, and the domain from which to
authenticate the user. If the domain name is omitted, it will first
search the local pc's account database and then search the pc's
default domain for a valid account. Also note that the account's pwd
is passed into the SU utility using the echo command.
Security concerns –
- users could read user ID and pwd from application object in
NWADMIN
Solutions –
- Workarounds - conceal user ID and pwd as macros – very little
added security
- mark the apps plugin dll as only readable by administrators
- Use Option 4a - This can be used in lieu of option 4 to get
around some security concerns. Make sure users do not have read
authority to the f:\passwds directory. Assign read privileges to
the WS objects for this directory. Users will not be able to see
this directory, but when the app is called with system
impersonation then the app will be able to read the file to pipe
in the users pwd.
A different set of users and pwds can be created for each
application you want to secure. This way you can extremely limit
what a user can do inside of each app by restricting the authority
for each user to just the minimum rights to use that particular
application. Great for making sure users don't accidentally move or
delete directories while outside of the application. |
03-Apr-05,
