Author Topic: Certificates  (Read 1910 times)

reelmike

  • Newbie
  • *
  • Posts: 3
    • View Profile
Certificates
« on: July 30, 2014, 01:33:50 AM »
Hi Reid,
First off, just want to say how awesome your book was, and what a tremendous help it was in setting up my first server! I simply can't wait for #2, and the rest of the series!

When I first setup my server, I installed my SSL cert right away, and secured all my services... later on, when I started Open Directory, OD created 2 new certs for me: one of which is now securing my OD.  Should that be right? Or shouldn't my 3rd Party signed SSL be securing that service?

The other cert OD created was the "Code Signing" cert... should I take the time to install a 3rd party signed Code Signing cert here, or should I just leave the default one in use?  This server is being used for a small company 50 units or so, but I could see this growing to almost double that, if we really start using Profile Manager more and more.  Thoughts on the Code Signing cert?  And do you have any tips for installation?

I used openssl commands (instead of Server.app GUI) to generate my CSR for my SSL.  Can I use that same CSR for my code signing cert? Or do I have to generate a separate CSR for that?

Thanks Thanks Thanks!
MM

Reid Bundonis

  • Administrator
  • Full Member
  • *****
  • Posts: 107
    • View Profile
Re: Certificates
« Reply #1 on: July 30, 2014, 09:04:52 AM »
Thanks so much.  I am so close with the second book it hurts.  But this summer has been unbelievably busy.

So first question.  Who did you buy the cert from?  There seems to be varying levels of success based on who issued the cert.

Now, I have done both.  I have forced the cert to apply to OD and I've left it none.  The beauty of OD is that, if you are doing it right, it is only exposed to your LAN traffic and you, the admin, and users are never notified if there is an SSL issue.  There simply is no interface to alert you of self-signed, expired, etc.  So, I will admit, I have systems out there that are deployed in both ways.  Some I will force the use of my cert, others I discovered later that OD is set to none and I never realized.

Next, code signing.  This is one of those areas where in my head I say, yes, I must get a valid code signing certificate.  However, I have not yet done it at over at least 15 Mavericks server deployments with Profile Manager.  Now, it might be a budget thing.  But, I think it also is a practicality thing.  In my experience, I am supporting mostly Mac OS, not iOS.  So the systems all stay on the LAN (or come back).

Also, my use of Profile Manager has mainly been to provide mobility settings and the main ssl cert covers profile manager web interface.  This is where the "self-signed" disruptions appears.

I need to run out, but I will post more later today.

reelmike

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: Certificates
« Reply #2 on: July 30, 2014, 02:28:37 PM »
Awesome... this is good stuff!

I bought the Code Signing Cert thru GoDaddy... which, I've now come to the realization, that might not be the best choice.  Our company already has an account thru them, so it seemed logical.  But, over this last weekend, I had a dev friend tell me that he doesn't necessarily trust them... I beginning to rethink it.

Here's what I'm trying to ultimately do:
Our company has many employees off site... I'd say about 85% of our staff don't work in our building, and may never touch the LAN, and they all have company issued computers, all OS X.  This is our first attempt at any type of MDM deployment.  Most likely only a "select" few will have full web portal access (admins), to enroll devices, and or manage profile settings.  Everyone else, who wants to enroll an approved device, will most likely download and install the enrollment profile on their computer (because everyone is remote, I can't get "hands on" with the computers).

Right now we are only looking at OS X settings, no iOS yet, but that will probably come down the road.

That being said, and looking at what you said, I see 2 possible answers:

1. Yes, secure OD with the SSL that I've already installed on the server, and yes, sign profiles with a CA issued Code Sign cert.  That way the OD is secured for "out-of-the-building" access, and the code cert is solid as well. Distribute the enrollment profile thru a web link for people to enroll computers.

2. Yes, secure OD with existing SSL, but instead use the self-signed Code Sign cert.  Then, open up web portal for users to enroll their own devices (with heavy restrictions, placeholders, etc.)... my question here would be would they still have to download the trust profile first, to trust the server, or does the SSL curtail that?

I guess the real question here is how do I get many people to enroll their computers the easiest/fastest/least-hoops-to-jump-thru way?
I guess perhaps I can just distribute both the trust profile and the enrollment profile on their own for people to install (without them having to use the web portal, which is what I'm ultimately after)?

Sorry to bombard you with so many questions, than you so much for your help with this!

BTW, I told another person about your book, and I have to say it's the best blend of tech-talk, and non-tech talk I've seen on OS X Server... it's really well written.  I'd even go as far to say your book is light years ahead of the Lynda.com videos... :)

Reid Bundonis

  • Administrator
  • Full Member
  • *****
  • Posts: 107
    • View Profile
Re: Certificates
« Reply #3 on: July 30, 2014, 08:55:19 PM »
Thanks for the great compliment!  My goal was to write conversationally but to also convey real world experiences.  One of the things that I've felt is missing in our community it candid "this is how to do it when" type of advice.  If you get a chance, drop some feedback on the iBooks Store.

So some thoughts.  Book 2 has a whole section on Profile Manager but I will give you a preview and get you thinking about how to implement.

Quote
Here's what I'm trying to ultimately do:
Our company has many employees off site... I'd say about 85% of our staff don't work in our building, and may never touch the LAN, and they all have company issued computers, all OS X.  This is our first attempt at any type of MDM deployment.  Most likely only a "select" few will have full web portal access (admins), to enroll devices, and or manage profile settings.  Everyone else, who wants to enroll an approved device, will most likely download and install the enrollment profile on their computer (because everyone is remote, I can't get "hands on" with the computers).

Ok, so a few questions.  Do you buy the machines, receive them at headquarters, image the machines, and then provide to the employee?  If so, then enrollment can occur on the LAN and all that is exposed is secure web to communicate to Profile Manager.  The user does not even need to be provided access to Profile Manager's portal as the base profile is already installed.

Now, if you are drop shipping units to remote users, then you have another deployment model that you might need to pursue.  We are doing this (called thin imaging) using JAMF in a number of cases.  Basically, the user receives the machine, turns it on, and then visits a web page to enroll the device into management.  Once the device is enrolled, policies take over and software, configurations, settings, etc, are delivered to the device or via Jamf's self service.  Now, Profile Manager can do the same for config profiles.  You can allow users to create a local account, visit the My Devices page, authenticate as their domain credential, and enroll.  Once done, you have the ability to manage those remote devices including remote wipe and future profile pushing.  I suggest this method as the remote users will likely have accounts on the domain in oder to VPN, connect to file sharing, etc.

I must diverges.  This is one of the debates of Mavericks and beyond.  Do you need a directory system?  iOS clearly says no.  There is no "user."  A user account is irrelevant to access and general use of the machine.  All management it applied at the device level.  But, OS X is different story.  So the question comes down to do to bind to a directory system?  And, if I have mostly remote users, what value does it add?  Considering the most Profile Management profiles can be applied at levels higher than the user, it is very possible to simply hand out a machine, allow a user to create his own account, and then force enrollment to allow management settings.  After all, the benefit of binding is to allow single sign on.  But if you are not on the LAN and you do not experience login window, you do not benefit from single sign on.

I know that Apple is putting this question in the minds of many Windows admins.  I remain a fan of centralized directory systems and they are not going anywhere as long as AD is the kind of corporate.  But the direction that Apple is moving is clearly stating that a centralized directory system and the need to bind system to it is a mode to be challenged.

Quote
That being said, and looking at what you said, I see 2 possible answers:

1. Yes, secure OD with the SSL that I've already installed on the server, and yes, sign profiles with a CA issued Code Sign cert.  That way the OD is secured for "out-of-the-building" access, and the code cert is solid as well. Distribute the enrollment profile thru a web link for people to enroll computers.

2. Yes, secure OD with existing SSL, but instead use the self-signed Code Sign cert.  Then, open up web portal for users to enroll their own devices (with heavy restrictions, placeholders, etc.)... my question here would be would they still have to download the trust profile first, to trust the server, or does the SSL curtail that?

I guess the real question here is how do I get many people to enroll their computers the easiest/fastest/least-hoops-to-jump-thru way?
I guess perhaps I can just distribute both the trust profile and the enrollment profile on their own for people to install (without them having to use the web portal, which is what I'm ultimately after)?

Keep in mind that each service is different.  OD is LDAP and Kerberos.  Profile Manager is available over the web and requires access to Apple's servers.  That being said, the system SSL certificate is used to secure services.  This includes web and OD.  But, when talking about Profile Manager, the SSL certificate ensures that the SSL connection to MyDevices and ProfileManager pages is secure.  The code signing certificate is to sign the configuration profile payloads.  This is a big difference.  One is a service, the other is a payload.  The code signing is the same as signing a software installer.

So far, as mentioned, I have not purchased a code signing cert as I have not needed to support systems outside the LAN yet.  Or, I should say that while devices leave the LAN, they are already under management and will eventually return to the LAN.  In this case, I've not found it necessary to purchase the code signing cert.  (It is on my list to do).  Also, the end user is really not notified of unsigned payloads.  Sure, if they actually look in the Profiles preference pane they will see it, but so far, no one is contesting.  Once again, I see this as being more important to iOS devices.

So I hope that helps out.  While I am very opinionated  ;) I don't have all the answers when it comes to the Profile Manager stuff yet.  It is finally usable, but the methods of use are so varied.  I am a huge fan of the volume purchase plan, and finally have come to terms with the loss of MCX.  But Profile Manager still can support many levels of use.  As mentioned, you can hand out devices and enroll.  You can bind devices, then enroll.  You can set policy at the device, the group, or the user.  But, if you are managing at group or user, you must bind.  It can get complicated deciding what you want to do.  Of all the deployments I've done so far, by far the easiest one was a 20 station SAN deployment.  These are all Mac Pros, sitting indefinitely in the office.  No chance of leaving.  I rolled out OD, turned on Profile Manager.  Created placeholder records.  Bound the machines to OD.  Enrolled into Profile Manager.  Logged in as the user.  All is right with the world.  But mobile devices change the paradigm.

Let me know if that helps.

reelmike

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: Certificates
« Reply #4 on: August 01, 2014, 02:12:47 PM »
Yeah, this is more information than I could have asked for! I can't even begin to tell you how much this helps, and how much I appreciate you taking the time to read all of this: THANKS!

You bring up lots of great considerations... I think I'll end up using a little bit of each methods: buying/deploying and "thin provisioning".  To answer your question, a little bit of both happens: I sometimes receive the machines, and set up the machines at HQ, and sometimes we drop the units straight to the employee...

The biggest things, for now, we are trying to accomplish with Profile Manager is to be able to secure units (having the ability to remote lock/wipe, etc...)... I think as we move along we will add more payloads, and also consider adding iOS devices, but not until I can test further.

As far as the SSL stuff, and Code Sign cert stuff, I may just leave things the way they are setup for OD and Profile Manager (signing configurations) by default, or perhaps apply my system SSL to OD... I have yet to find any solid documentation on how to properly implement the CS cert (either thru Apple, forums, books, etc.)... and you are not the first person I've seen say that in some/most cases, it's just not necessary.  I don't blame you for not knowing, and for not actually testing... I guess if most people aren't talking about it, then it most not be as big of deal as I'm making it. Maybe I'm overthinking it too much.

I am excited about using VPP... that's another reason our company is looking into a lot of this stuff... there are some core OS X apps we'd like to distribute to employees without having to "share" an Apple ID, and actually be legitimate about things.

Again, thank you for the advice and considerations... I'm headed over to iBooks to write a great review of your first book!  Can't wait for the rest... good luck!