Not sure if this is the right way to go about things..

currently I am specifying the GUID for a machine to boot to PXE & into RIS.

i dont want to have to do this input but want RIS secure so unauthorised people cannot run installs. What is the best way to restrict access to RIS menus from PXE without having to specify a GUID?

Hi,

Do you mean:

"What is the best way to allow only certain people to log on to a RIS server through PXE booting?"

or

"What is the best way to limit access to certain menu options within the RIS menu system once a user has logged on?"

Thanks,

Andy

Edited March 14, 200620 yr by Fencer128

Putting ACL's on the .sif file associated with the image in RIS, can be viewed as a delegation model...

If a guy has Read and Execute on the .sif file, he or she will see tha images presented in the boot menu, however, if logged in as a dude with no permissions to the .sif, he wont see anything at all.

Best Regards

Tha Sausage Eater...

this is the one I was angling at... if you could help that would be apreciated.

"What is the best way to allow only certain people to log on to a RIS server through PXE booting?"

if u mean the my entry, the "solution" is just to have the group designated as "ris installers" with Read & Execute on the specific .sif file for each image that they are allowed to install/use. If all other "not allowed to installed from RIS" cannot see the .sif files (does not have Read & Execute), then they wont be able to get those shown in the .osc menus...

Best Regards

Tha Sausage Eater...

if u mean the my entry, the "solution" is just to have the group designated as "ris installers" with Read & Execute on the specific .sif file for each image that they are allowed to install/use. If all other "not allowed to installed from RIS" cannot see the .sif files (does not have Read & Execute), then they wont be able to get those shown in the .osc menus...

Best Regards

Tha Sausage Eater...

That's it. There are some more elaborate solutions available if you want to restrict access to certain builds to specific AD security groups, but it involves diverging slightly from the default OSC model (creating new OSC files, folders and adapting a few more file permissions).

Cheers,

Andy