Last week, we talked about password expiration, and the recent guidance that recommends doing away with them. But, those same papers recommended that you should beef up your password security in other ways. One way is by auditing the strength of your current passwords.
For years, the conventional wisdom in computer security has been to force users to change passwords every few months. The thought was that if a password were compromised, then an attacker would only have access to that password for a limited amount of time.
For the last few weeks, we’ve been looking at digital certificates and the Public Key Infrastructure (PKI) that makes them work. Last week, we looked at some design considerations for a Microsoft AD Certificate Services PKI. If you’ve decided to go ahead and set up your own in-house PKI, then this article will help you get started!
This week we will cover setting up the offline root CA. Then next week we’ll finish up with configuring an issuing CA and making sure that the certs and CRL are published so that your clients can use them.
This month, we’ve been talking about digital certificates and public key infrastructure (PKI). So far we’ve covered the basics of how certs work, and how to install publicly trusted certs for Exchange and IIS. This week, we’re going to tackle what’s involved in setting up your own PKI using Microsoft Active Directory Certificate Services (AD CS).
As the name suggests, AD CS is highly dependent on Active Directory.
Once you have a security certificate configured for Exchange, it’s time to start looking at other places where you need to install a cert. Internet Information Services (IIS) is used by many businesses to host Intranet apps and external web pages. This guide will show you how to request and install a certificate in IIS versions 7 through 10, for Windows Server 2008 to 2016.
Create a Certificate Request
First, you’ll need to create the Certificate Signing Request.
As we discussed in our previous article, properly configured security certificates are the key to secure communication over the Internet. And nowhere is security more important than your email system. If you host your own Exchange server, and you allow access to it over the Internet through OWA or EAS, it’s important that you configure a secure, trusted certificate to protect the information that your users transmit to it.
As a system administrator, one of your main priorities should be keeping your company’s data secure. But, that data doesn’t just stay in one place. It’s always on the move -- whether someone is checking their email, accessing a document on their phone, or connecting in with a VPN, data is constantly flowing in and out of your network.
For the last few weeks, we’ve been looking at how to create data retention policies for various services where old data may accumulate. This week, we’ll cover creating retention policies for on-premises Exchange mailboxes. The concepts are similar to Exchange Online, but the process to create retention policies is just a bit different for self-managed Exchange servers.
While SharePoint is a much more organized document management system than a regular file server, it can still become cluttered with old documents. And, as we discussed previously, old documents can cause storage, security, and liability issues. So, this week, we’ll show you how to create a retention policy in Office 365 for SharePoint Online.
Last week, we talked about the ins and outs of data retention policies. This week, we’ll get into the nuts and bolts of creating a retention policy for Exchange Online in Office 365.
Exchange Online gives you powerful options for managing retention policies.