Profile Manager Enrollment - iOS - Server Certificate Invalid

When I ment your FQDN'S should match on your OD Intermediate as well as Push certs, they should both be in the format server.domain.com if there is any digits added to the certs, then obviously dont muck with that. That is system created.

Since everything is bassed on certs with profile manager, it is ncessary that the FQDN of the certs are all in the same format, so your puch certs should have the same fqdn if you log into the web session where you revoke the certs as your intermediate cert.

Like I said .... your settings are so mucked up, that the best thing to do is start over. There is no need to actually reformat... Just clean up all of your old settings, go remove some certs, and reboot.

I may have a small issue trying to test profile manager in the lab since the support for .local active directory domains was not introducted until 10.7.3, and the lab DNS zone was not working properly with our primary DNS zone in production.

Once again I got stuck working today and spent some time figuring out how to drop the wiki database so I could move the mini to the lab :-)

Gota love it when apple changes procedures every OS :-)

Okay. I might argue the "obviousness" of the appended digit but certainly not your advice thus far. I'll likely give this a shot tomorrow evening. Stay tuned and thanks again.

Here is a link to another kb article of people having similar issues, and that some of my recomdations have helped reguarding rip out OD revoke all certs obtaining to OD / Push, run the script to wipe the DB, and start over.

https://discussions.apple.com/thread/3292024?answerId=17528893022#17528893022

When I first got this working, and from the support I had with apple it was a tough one, I must had reformatted over 6 times, what ever I did I had issues, and couldn't get things to work properly. In the end it was pretty simple, I just dont have much experience with certs. I came from more of a network / security background.

Let me know how you make out though!!!

ALL Hail burton11234! It Worked! :-D MANY MANY THANKS!

Burton: your steps were, as stated, "off the top of your head" but 98% accurate. I took the time to comment/note my experiences to make up the 2% clarity I needed below. Very aware that all users will likely not have the same experience through this given my personal level of experience with Lion Server rebuilds and the particulars of our server. None the less, your fix does support your claim... "CERT RELATED". So I am now able to enroll my iPad.

(Note: I still have one error when loading the default "Settings for Everyone" in My Devices - Profiles Tab. Error reads: Cannot Install Profile: Safari could not install a profile dure to an unknown error" There are possible solutions here or here but I'll submit a different post for that if necessary. May also be because the server isn't public facing and can't talk to the APNS service..)

Here are my comments/notes to your steps:

Step 1: “Stop All Services:”

(I Had to Log in - in Terminal - as local admin to do this – even though I was already logged in on the machine as such)

Step 3: Launch Serveradmin and connect to your server.

(…by choosing the OD Service/General Tab/Change Button)

Step 4: Kill profile manager.

(Stops devicemgr also before running but restarts it after)

(Ran sudo serveradmin stop devicemgr again before proceeding)

Step 7: (2) “Select Profile Manager ->”

Choose configure, once you configure it, it will setup OD for you under the proper host names.

“This will also create your certs needed”. Chose the intermediate SSL certificate at the end of this wizard. You can’t go forward w/o. Got a “This certificate isn’t signed warning – mobile devices will not be able to enroll in device management until they have been configured to trust your certificate”. Clicked NEXT – saw the big green check mark. Then DONE.

Step 7: (3) “I would suggust removing Kerberos and binding it to the AD realm…” I wasn’t clear on this and skipped the step.

“…join to the AD realm (sudo dsconfigad -enablesso)” Wasn’t sure about this either but (took a risk) and ran it anyway… All I got was:

>

>

>

Instinct told me to Quit Terminal before it returned to prompt and restart. (My machine was AD bound throughout)

Step 7: (4) “Login, and acquire new…”

(through Server App – not the web site)

Step 6: “- Make sure Server.FQDN Intermediate CA is selected.”

(In the pull down Menu)

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.

The ports I listed were Edge Firewall Ports, not server bassed firewall rules.

Those Ports will allow an iOS device to enroll remotly over 3g, and allow push services to work from the outside.

Here is a few good URL's for Apple TCP / UDP ports if interested.

http://support.apple.com/kb/ts1629

https://help.apple.com/advancedserveradmin/mac/10.7/#apdCA9A73CE-5F0C-4BDC-93E8- 2952C362FA3E

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?