27 Mar Apple SIP & Ivanti SESS: Requisite Knowledge for Successful LANDESK macOS Provisioning
From a LANDESK Management Suite architecture point of view, there are only three pieces that need to be in play in order to successfully get a Mac into a NetInstall state for macOS provisioning:
- You need an HTTP share on your Core server, Preferred Package Server, or any other HTTP Web server with your LANDESifiied NetInstall image.
- You need a properly configured Core server for the NetBoot service.
- You need a LANDESK PXE representative, configured with your NetInstall information, to respond to the NetBoot service requests from your Macs.
But, before we jump into the configuration of these three pieces, you need to understand some background information regarding Apple’s System Integrity Protection (SIP) and Ivanti’s Self-electing Subnet Services (SESS).
Apple SIP – For Better or For Worse
Beginning with OS X El Capitan, Apple configured its System Integrity Protection to prevent software from selecting a startup disk. Explained in detail by Rich Trouton, “SIP is designed to limit the power of root and to protect the system even from the superuser…with the goal of preventing system files and processes from being modified by third parties.”
Why did Apple do this?
Well, as discussed on the SIP WikiPedia page, “Apple says System Integrity Protection is a necessary step to ensure a high level of security. In one of the WWDC developer sessions, Apple engineer Pierre-Olivier Martel described unrestricted root access as one of the remaining weaknesses of the system, saying that “[any] piece of malware is one password or vulnerability away from taking full control of the device”.”
So how does SIP affect you when it comes to using the NetBoot service?
That will actually depend on your imaging process. If you start your NetInstall process by being physically present on the machine, even with SIP enabled, you may continue to:
- Use Startup Disk preferences: Choose Apple menu > System Preferences, then click Startup Disk.
- Use Startup Manager: Hold down the Option key while starting up.
- Hold down the N key while starting up to use the default image on the NetBoot server.
If your not physically present on the device, but do all of your imaging on a single subnet, the Mac will trust the NetInstall image without issue. Just make sure the Mac that is sending the NetBoot service request resides on the same subnet as the device that is assigned to respond to the NetBoot service request. Also, if the device that host the NetInstall image is different than the device responding to the NetBoot service request, make sure it too is on the same subnet.
If you find yourself outside of both of these scenarios, then you’re in the third scenario of trying to image Macs across multiple subnets and do not have someone physically present to kick off the NetBoot service request. This is the scenario in which SIP greatly impacts you. SIP is going to force you to make a configuration change to every Mac’s NVRAM to add in a whitelisted NetBoot server in order to run NetInstall across the subnet. And, unfortunately, this change requires a physical touch to the Mac to run the csrutil NetBoot add command.
So be prepared. Imaging a Mac across a subnet is going to require time and effort on you and your organization’s behalf.
Ivanti SESS – For Better or For Worse
In LANDESK Management Suite 2016, Ivanti introduced service automation platform titled Self-electing Subnet Services. This platform allows you to enable core Ivanti services, by subnet, and then ultimately forget about the rest of the configuration process. LANDESK Management Suite will automatically elect the best machine, per enabled subnet, to fulfill the service. As a benefit to this SESS process, if that device disappears, regardless of the reason, it will automatically find the next best suited device and have it host the service.
What does that mean for you?
Well, you no longer have to specifically target a machine to be run the specific Ivanti service. Take the PXE service for example. If you have hundreds of subnets, do you really want to define and manage hundreds of machines to be that PXE service? Enabling LANDESK’s PXE service on SESS, LANDESK will do all of the management and ensure your subnet is taken care of.
But what about Apple’s System Integrity Protection?
Ah, yes, System Integrity Protection. In short, SIP undoes and invalidates all of the goodness of Ivanti’s SESS.
If LANDESK Management Suite is constantly changing your NetBoot server, which is housed inside of the LANDESK PXE Representative service, then you’ll have no way of knowing what IP to whitelist and approve for your Macs to NetBoot to.
So what do you do?
Honestly, there is not a single, smoking gun here. You can always centralize your imaging process. Do all of your imaging from a single subnet at a single location. There are significant costs in both time and money in doing this, but it may be the best route for you depending on how many subnets your organization has and how distributed your Macs are.
If centralizing the imaging process is not viable, you’re going to have to take over the job of what SESS would do for you. Essentially, by subnet, you’ll have to identify and define which machine you’re going to use as the PXE representative and only deploy the PXE Service to that single machine. Doing this will ensure you can use csrutil on your Macs and specify the correct whitelisted server, but you are now back to managing every single machine, by imaging subnet, that’ll handle your PXE/NetBoot service. Again, this means you’re going to have to plan for the time and effort that is going to be required to make macOS provisioning a reality.
Configuring LANDESK Management Suite for NetInstall
Alright, let’s discuss how to configure the LANDESK core server and PXE representatives to support the LANDESKified NetInstall image you previously built. If you’ve missed the prior two blog posts discussing how to build your NetInstall image, you may want to start there first:
- NetInstall or NetBoot: Which one is needed for macOS imaging?
- LANDESK startup disk stamper NetInstall image failing? I bet I know why.
In order for the LANDESK PXE representatives to download your NetInstall image, they need to be able to access the image file from an HTTP share. You can choose to use one of the default HTTP shares LANDESK builds out on the core server during the installation process or you can build your own share on the LANDESK core server or another server altogether. If you’re unfamiliar with building a web share in IIS, see this previous post.
In today’s example, I’m just going to use the ‘landesk’ web share created at time of install. The physical path to this share, assuming you chose the defaults, is \Program Files\LANDesk\ManagementSuite\landesk with the HTTP path being http://coreservername.domain.extension/landesk.
I like to create a new folder inside the vboot folder found in the Landesk folder and name it NetBoot, so the physical path I end up using is \Program Files\LANDesk\ManagementSuite\landesk\vboot\NetBoot with my HTTP path being http://coreservername.domain.extension/landesk/vboot/NetBoot. Web URLs are case sensitive, so pay attention to your capitalization.
Once you have your folder structure established, copy your NetInstall image to the physical path created.
IIS MIME Type Configuration
Configuring IIS with the appropriate “.” MIME type is absolutely critical for your LANDESK PXE Representatives. If you’re unfamiliar with what a MIME type is, basically, on any Web server you need to specify the types of extensions and associated content that can be served by the Web server itself. Because your NetInstall is a folder of files, some with no extension at all in some cases, we need to tell IIS that it can serve out files with no extension. This is done by specifying the MIME type of “.” or all with IIS Manager.
- Open Internet Information Services (IIS) Manager.
- Browse to your Default Web Sites in the menu tree and select it.
- From the panel on the right hand side, double click on the MIME types button.
- From the actions panel on the right, click on the the “Add” hyperlink.
- Enter a “.”, without the quotes, for the file name extension and “application/octet-stream”, again without the quotes, for the MIME type and hit OK
Core Server Configuration
Now that we have our NetInstall file housed and IIS configured so that the NetInstall image can be transferred when requested, we need to tell LANDESK Management Suite where our NetInstall image is and for what hardware it should be used for.
- From the LANDESK Console, open Tools > Provisioning > OS Provisioning.
- On the Operating System Provisioning toolbar, select the Preboot dropdown button and click on the Manage Netboot Image Mappings.
- Supply the HTTP path to your NetInstall image, leaving out the name itself. Using the text from the example above, it would be http://coreservername.domain.extension/landesk/vboot/NetBoot.
- With the path provided, click Browse button to select your appropriate NBI.
- If you have multiple NBI files, choose the one that will work with the greatest number of hardware platforms.
- Configure any unique device models that will need an NBI image different from the default. The list of device models will be automatically populated from the LANDESK inventory.
- Click OK.
Enable the PXE SESS & Validate Agent Settings
You’re almost there!
The final piece to put in play is the LANDESK PXE Representative. As I mentioned previously, this is a service that is now enabled or disabled at the subnet layer. Once the subnet is enabled, you then need to target one or more machines, with the appropriate Agent Setting, granting it the ability to potentially serve as that service provider.
Enable PXE by Subnet
- From the LANDESK Console, open Tools > Configuration > Self-electing subnet services.
- Select PXE Services from the menu tree.
- Find your desired subnet from the list, right click and select Enable
Create and Assign Agent Settings
- From the LANDESK Console, open Tools > Configuration > Agent settings.
- In your Public Agent settings area, select Client connectivity and either edit an existing setting or create a new one.
- Select self-electing subnet services from the menu tree and check the box “Enable self-electing subnet services.”
- Select PXE service from the menu tree and check the box “Enable PXE service.”
- Hit Save
Nice work! You’re nearly finished.
If you edited an existing Agent setting, already deployed to all of your desired machines on all of your desired subnets, and those PXE service boxes were already checked, then wait about 10 minutes and the PXE representatives will begin pulling down the NetInstall image. You don’t need to do anything else.
If you edited an existing Agent setting already, again, already deployed to all of your desired machines on all of your desired subnets, but had to add a check box for one or both of the PXE options, then the next time the PXE representative is scheduled to run a vulscan it will inherit the changes defined. Once inherited, the PXE rep will subsequently pull down the NetInstall image file(s). Again, you shouldn’t have to do anything else.
Now, if you created a new setting or edited an existing setting that you subsequently need to deploy to one or more machines, use the steps below.
- While still in the Agent Settings window, click on the Calendar/Clock icon, it’s the second one in the menu bar and then select Change Settings.
- Give your task an appropriate name, I named mine “PXE SESS”
- Find the “Client Connectivity …” from the list on the right hand side of the panel and click on the corresponding Keep agent’s current settings window area.
- Find your newly created or recently edited Client Connectivity Agent Setting and select it.
- Now set your desired Task Settings (policy, push, policy supported push) and desired portal settings (required, recommended, optional). I used a policy-supported push and required.
- Add in your Targets
- Schedule your Change Settings task
You’re now finished. Within just a few minutes all of your machines should receive their new Agent Setting and the service should automatically elect a representative.
If you’re NetBooting across more than one subnet and need to ensure that only your specified machine is chosen as the representative, then make sure you only deploy the agent setting task with the PXE service enabled to a single machine per subnet. Doing this, guarantees the PXE service will only run on the machine you choose, blacklisting all other.