-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.

6
  • 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: docs.microsoft.com/en-us/windows-server/networking/…
    – 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?
    – Shaamaan
    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.
    – Shaamaan
    Jun 21 '18 at 16:47
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

5
  • 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...
    – Shaamaan
    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.
    – Shaamaan
    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.
    – Shaamaan
    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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.