Post-imaging processes with proxies

The command I'm using to set the proxy on computers that were setup long before the proxy came into existence:

networksetup -listallnetworkservices | grep -v "*" | while read a; do networksetup -setautoproxyurl "$a" http://ourproxy.company.com/accelerated_pac_base.pac ; done

i just need a way to apply that so it is in effect at the point when the computer starts the enrollment process.

I believe if you wanted it done during enrollment, you would need to avoid using commands and make it part of the base image. I know it is ugly and not ideal, but we used to have a PAC file too and I had to put it on the base image to make it work right during enrollment.

Depending on how you create the it you can inject that setting into the DMG

@AVmcclint Is the proxy JAMFCloud or something then?

I'd bug the security folks about an exception for that too.

You can't manage & secure your Macs if they cannot contact the JSS...

Our JSS is hosted internally, but the whole MDM/APN thing needs to be reachable ... and it is now but only through the proxy... as long as the computer is configured for the proxy. But How do I configure a computer for proxy at the imaging level if it can't establish communication to get the JSS policies?

@AVmcclint so your proxying internal addresses?

@charles.hitch I like this idea.

I found the Payload-Free Package Creator from Der Flounder and just created a package and uploaded it via Casper Admin. I checked the box to Install on boot drive after imaging. My question is do I now include that package in the image configuration or do I set a policy on JSS? And do i need to set a priority?

@AVmcclint include it in the image configuration.

@bentoms No we don't proxy our internal addresses. When I tried to image a Mac right after the initial MDM proxy problem was resolved, I discovered that the freshly imaged and rebooted mac just sat there and never checked in or began enrollment or anything. I thought maybe I forgot to set something so I put a QuickAdd package on the computer and installed that. While I ran it, I displayed the progress log by pressing Command-L and I watched.... I watched it fail and fail and keep failing. The errors basically indicated that the computer couldn't talk to apple's servers. So while this was failing over and over, I decided to manually set the proxy information and almost as soon as I clicked Apply in the Network system prefs, the failures turned to successes and the enrollment proceeded as normal.

As I understand it, MDM really is the new Golden Triangle. There needs to be a three-way trust between your JSS, the client Mac, and Apple's MDM servers. If the client can't talk to Apple to do what happens with MDM, then it will fail. If the computer already knows about the proxy, and the proxy is configured to allow it, then it will work, but if the Mac has no idea about the existence of a proxy, then it's going to try and connect directly through the internet which will fail in our case. I am going to try the suggestion by @charles.hitch. I think I can follow the logic of it, and it sounds like the best way to make sure the near-naked, freshly imaged Mac knows about the proxy BEFORE it begins that 3-way trust needed for enrollment. I hope to run a test of it tomorrow.

@AVmcclint if no JAMF Binary commands are being run.. Something else is afoot.

They don't go via Apple but from client to server.

Agreed with @bentoms that you should be able to enroll without proxy set, but it wouldn't list as an MDM capable client in JSS. I am wondering if you are running into the issue where the OS needs to detect new network hardware and enable it which the "apply" might have done when you configured proxy manually.

That said putting the proxy in the image is relatively easy and gets everything setup correctly right off the bat.

Also I will note that you don't need to setup proxy on Thunderbolt Bridge. You might want to add some logic to run through the list of network service and only set the proxy for the ones you want.

Lastly I'll give you a hint that you should create a self service policy that will run through all the network services and set proxy. When a user plugs in a new network adaptor (say a thunderbolt display) the adaptor gets created then and won't have proxy set.

no luck opening up outgoing 5223 from client subnets? i think https is just a fallback mechanism for APN traffic

@charles.hitch your suggestion of a payload-less package with the script that has the command to set the proxy worked! However I discovered something I don't currently understand, but could live with if I needed to.

After the imaging was successful, the computer restarted.
At the first restart, I got the black screen saying Casper Imaging is finishing installing software.
During this time I monitored JSS and saw that the freshly imaged computer was communicating with JSS and checked in, where before it would do nothing.
HOWEVER, after a minute or so, the computer restarted again. This was unexpected.
When it came back up again, I let it sit at the login window as I usually do to let all Policies with Enrollment triggers run.
After several minutes, the Policy log never showed any of the Enrollment trigger policies running.
I logged in as the local admin and the Login triggers fired up and those login policies ran just fine.

My questions: 1) Why would the computer do that 2nd reboot after running the payload-less script? There's nothing in the script that tells the computer to restart.
2) Why wouldn't the enrollment trigger run after that 2nd restart?

So the reboot to the lock screen is normal when you have packages that install on boot drive at image time. That used to be used primarily for adobe installs and there is a temp account called adobetempacct (or something like that) that gets created and actually runs the lock screen. The reboot that happens after the lock screen is also normal because the process jamf sets up to install that package also has to tear down the temp account that gets created.

With regard to the enrollment triggers, I am not sure. We see the enrollment triggers occurring on our system. What does the jamf.log say at that time? Any errors?

There are no errors, there's no sign of it doing anything. I let it sit for 10 minutes (more than enough time for enrollment triggers to complete) and nothing happened until I logged in and the Login triggers started.

What proxy are you using and is it an authenticated proxy? I agree, proxies will be the death of me as well, but we are slowly trying to work around some of the issues. Not sure if you are doing SSL inspection or Auth, but those have been some of our pains. Macs and proxies just don't work very well together IMHO.

We are using Blue Coat authenticated proxy. And they have made it so that 100% of all outbound traffic must go through the proxy. There's no way I can work around it by just disabling the proxy settings. Any information beyond that has been kept from us.

The person who is overseeing the whole proxy project is under the impression that every executable, every .app and .EXE, every binary and background process running on every computer is proxy-aware and shouldn't need exceptions or holes in the firewall.