-1

As the title suggests, I'm trying to set up a new Windows domain. Seemingly a simple thing, and one I've already done before, but this time around, management wants this to be synced up with Office 365 and generally be publicly accessible.

OK, well, we have the domain name registered, and we bought a wildcard SSL certificate to go along with this. I've already got the basic DC server ready.

Now, I'd like to set up a proper CA for this domain. I was hoping a wildcard certificate would be enough to let such a CA create valid certificates for whatever else I may need that will be in this domain.

Unfortunately, I'm having some issue, and I can't really find a guide on how to do this. Specifically, when configuring the CA I can't actually use the certificate ("imported certificate does not match chosen CA type"). So, is what I'm planning to do even possible? It seems like it should, but the error suggests otherwise.

Can someone point me in the right direction, please?

EDIT:
I've just found this ServerFault question, which appears to answer the basic question of "can I use the wildcard to sign new certificates?". The answer, sadly, appears to be "no". That said, I'd still like to know what my options are to make things nice and smooth on the new domain.

MBender
  • 381
  • 2
  • 8
  • 25
  • 2
    The process for standing up a certificate authority using a certificate from an existing authority is completely different from requesting a wildcard certificate. You need to create your own CA certificate using this documentation: https://docs.microsoft.com/en-us/windows-server/networking/core-network-guide/cncg/server-certs/install-the-certification-authority – Greg Askew Jun 21 '18 at 13:40
  • @GregAskew That much I figured out already. The question is: is there anything I can do to make life easy using an existing wildcard certificate? Is there a point in installing a local CA in this case? – MBender Jun 21 '18 at 13:57
  • what kind of nice and smooth things you are talking about? – Crypt32 Jun 21 '18 at 15:19
  • 1. You don't need a CA in order to sync your on premises AD to Azure AD/Office 365. 2. When your boss says that he/she wants the on premises domain to be "publicly accessible" what does he/she mean exactly? – joeqwerty Jun 21 '18 at 16:25
  • @joeqwerty The domain is akin to "mydomain.com", which exists in the public space, as opposed to "mydomain.local", which only exists inside the company network. Perhaps calling it "publicly accessible" is a bit of a stretch - websites / services still have to be manually forwarded via our firewall, but the idea is that they should have the same internal and external addresses. Another idea is to sync up with Azure AD / Office 365, so that new computers could (in theory) be added if they just have internet access, as opposed to LAN access. – MBender Jun 21 '18 at 16:47
  • I think Joe is correct, you don't have a use case for a CA. – Greg Askew Jun 21 '18 at 18:27

1 Answers1

1

I guess I'm not understanding the question or the problem. Your "public" domain name is public and will remain so. You can continue to use it as you always have. Office 365 changes nothing in that respect. Your internal domain name will remain the same. Nothing will change in that respect.

You'll add your public domain name in Office 365 as a verified domain. You'll then create a UPN suffix in your on premises AD that matches that verified domain. You'll then assign that UPN Suffix to your users. You'll install Azure AD Connect so as to sync your on premises AD users, groups, and contacts to your Azure AD/Office 365 tenant. This will facilitate Single Sign-On to Office 365.

You'll continue to forward websites/services from your public namespace to your internal websites/services just as you have been. Nothing will change in that respect.

It's not clear to me what you think is going to happen or how you think this works. Can you clarify what your concerns are?

As for joining devices to Azure AD rather than the on premises AD, have a read here:

https://docs.microsoft.com/en-us/azure/active-directory-domain-services/active-directory-ds-compare-with-azure-ad-join

joeqwerty
  • 109,901
  • 6
  • 81
  • 172
  • My initial (wrong) impression was that, using a wildcard certificate and a CA, I could issue domain-wide certificates for... well, things, in an automated fashion. Using a CA I could request said CA for a dedicated certificate for a new website instead of relying on sharing the wildcard certificate. Computers in the domain would be more trusted via RDP (as each could have an identification certificate), and so on... – MBender Jun 22 '18 at 10:20
  • I can definitely live without a CA and just set up the Azure sync as described. I was just hoping there's still some way to automate things. – MBender Jun 22 '18 at 10:21
  • You're kind of all over the place, no offense intended. We've established that you don't need a CA for Office 365. Now you're talking about "automating" things. Automating what exactly and how does that relate to either a CA or Office 365? The way I'm seeing it you're working on 3 separate tasks/goals: 1. Migrating to Office 365. 2. Installing an internal CA. 3. Automation (of what has yet to be determined). Maybe you could post a separate question for each of these items so that we can give you "focused" answers. That or rewrite this question to clarify your exact goals. – joeqwerty Jun 22 '18 at 11:12
  • You're right, and I apologise. I've never did these things and I feel like I'm learning as I go - which is hardly ideal. Thus, I probably end up with multiple minor issues which all meld into one issue in my head. – MBender Jun 22 '18 at 13:41
  • No apologies needed or necessary. We've all been there and we're all learning as we go. Azure and Office 365 are the way of the future so the experience you get with it will be invaluable to you in your IT career. – joeqwerty Jun 22 '18 at 15:30