Profile Manager Enrollment - iOS - Server Certificate Invalid

Good Job!!!! :-)

Yeah sometimes its easier to take a few steps back, and start over. At least you didn't have to export everything from Open Directory and re-import....

The part that you didn't understand was the part about removing yourself form the kerberos realm on the OD master, and joinging the AD realm.

It only helps a few tings with MAC users using SMB shares. Kerberos works behind the scnese and creates tickets when trying to access shared drives. Its one step closer into SSO for shared drives.

Oh okay - I only had a few users and groups to re-establish so it was no big deal. BTW, I closed the open ticket we had with Apple on this and recommended they take your repair recipe, review/refine it and publish it in the Administrator guide... They have the URL to this thread...

Thanks again - you went above and beyond. Much appreciated.

Sounds good! Im happy I could help, and got you up and running!

Just remember that what is stored in devicemgr (profile manager) is not backed up user management for open directory. If your pushing policies to anything under 10.6 you still need to create the setup in workgroup manager on the server so you can control both environments.

I actually got lucky on who I talked to at apple, he wouldn't support the AD / OD without having a service contract, but was very helpful and had some good advice!!!

It would be nice if apple used the info from the forum and compiled a nice howto. I have helped a few people know from my experience and its not like its impossible. Their documentation is just not very straight forward on 10.7 like it was with 10.6.

The default profile is not used by my organization, that is just a profile that the user can actually download to their device if they chose.

We push out the profiles through profile manager, and you can also make it so the user is not able to delete the pushed profiles (Profile Manager Web -> Group Settings -> General -> Security -> Never / Authorization)

If the device is behind a firewall you need these ports open below in order to push to wifi / 3g on the internet.

ping

https

tcp - 2195

tcp - 1640

tcp - 2196

tcp - 5223

Okay - We're we're an all 10.6 > shop so hopefully our Workgroup Manager days are done. Got it on the Never/Authorization. Good advice. Ports specified are open. Next task is to figure our how I can let in APNS traffic only, (if possible) for more testing since we're still in test environment mode.

Thanks for clarification. I've seen both port related resources (thanks). This has been another challenging area since I have to meet extra stringent security measures here. I've been wanting to know what are the minimum ports (or protocols/services) that need to be open (on both firewalls) if we're ONLY doing iPad policy enrollments/enforcement?. Would it only be the following based on the Services and Ports list?

The only ports that are open from the DMZ to Untrst are the ones listed below. Those were the ports I found needed to be opened in order to enroll a iOS device. Although there is nothing stoping anyone from enrolling a laptop to those ports. Im not sure if you can be that restrictive since the same ports seem to be used for push services on OSX as well as iOS.

ping

https

tcp - 2195

tcp - 1640

tcp - 2196

tcp - 5223

You can restrict access by not using active directory, or if you use active directory, create a security group in AD and then apply that security group to Server Manager -> Select Server Name -> Select Access -> Select Profile Manager.

With applying users / groups to profile manager you shoudl be able to restrict who is allowed to login to the site via web. You could always allow these users at first time connecting to login, and then remove access from them.

burton - I have a similar scenario in that I'm just trying to get device enrollment to work internally. I ran through your steps posted on the prior page, and I'm still getting an invalid ota_service cert error.

In fact, my non-iOS device enrollment is now failing as well, whereas before that part was at least working.

Any ideas?

If you have a non-iOS device you can enroll without using the FQDN. I have been able to enroll with just using the short name, which you should get away from doing.

What was the URL you were using to register? ex. Server.domain.com

My guess its a mismatch between DNS entry on OD Cert and Apple Push Certs and the FQDN of the server on the network.

You were correct with using the shortname to install on the non-iOS devices. However, I've checked the certs and they all match the FQDN of the server. So unless I'm missing something here, I'm still left scratching my head...

😕

Can you do forward and reverse lookups of the server on the network your iOS devices are on?

Are you using DNS Service on the OSX server?

If you log into the section on where you can register your push certs from apple, It brings you in a web interface. It generates 4 certs with the FQDN. If you have wiped the server and changed hostnames it may have multiple FQDNS for the certs. Do those certs corespond to your correct FQDN?

When you said you follwed the steps, did you start over, like I had mentioned and wiped everything?

reverse and forward lookups - yes

I'm not using the DNS service.

The certs correspond (servers were having problems last week, so that part took forever).

And yeah, I followed everything you had posted step-by-step.

I have posted a few different places and everyone was able to get things working at some point or another.

When you re-created your OD master, with the FQDN did you revoke your apple push certs?

Did you remove all of your certs after destroying your OD Master?

I moved a mini I had to our lab, on a different domain and everything, just removed the certs after removing OD, and wiping devicemgr. No need to reformat... I didn't have any issues at all enrolling after everything was said and done.

There has to be some mismatch in what was done when you went through the instructions. Maybe there is an invalid cert that was left lying around before you re-created OD?

burton, thanks for your help. It took purging everything again, but it finally worked. Based on your experience, is there a need to open anything besides 2196 and 2195 if I don't plan on device enrollment occurring outside of my environment? All I want is remote wipe capabilities to occur on iOS devices and the ability to perform remote udpates/policy changes through profile manager.

Your more then welcome!

Unless the networks are seperated by a firewall, you dont need to open any ports. If your network is seperated by a firewall you will need to open a few ports. Our mini in the dmz serves just iOS devices and these were the ports opened inorder enroll and push services. Obviously ping was enabled for verifying the device was up, and https was browsing the to the web page so you can enroll the device. The other 4 ports were for the process of enrolling to work and push services.

ping

https

tcp - 2195

tcp - 1640

tcp - 2196

tcp - 5223

So more of a verification on my logic here 😉...

I'm assuming that all communication from Lion Server to the endpoint occurs via Apple Push Notification Services. Meaning that if I wanted to send a remote wipe to a device, I would need those ports open through my firewall in order for that to occur?