AWS Console has its own authentication/authorization directory using IAM users, roles and policies. On top of that, they also offer multi-factor authentication, so your logins are much more secure. But, I wanted to see how I can use Okta for SSO between my AD domain at home and AWS. The setup is very simple as you can see from this diagram.
On the left side, AWS is missing – but you get the point. In my case, I’ll have two AD groups, AWS Full Admin and AWS Read Only. I also have two AD users, admin.user and ro.user. If you haven’t integrated your AD with Okta it’s time to do so.

Okta

Go to the Okta dashboard and from the menu go to Directory | Directory Integrations.

Click on Add Active Directory and proceed so you can download an agent that you have to install on a member server with at least 8GB RAM. You can also install it on a domain controller, which I did in my lab, but I guess it’s not recommended. You’ll see this page telling you that Okta is waiting for your AD to connect.

Go ahead and install the agent. You’ll be prompted to specify the domain name (andreev.local in my case), create a service account OktaService or choose an existing one, choose a proxy to connect to Okta servers over HTTPS (if needed) and finally you have to specify your Okta domain, e.g. the prefix for your Okta landing page, https://company.Okta.com. You have to type -company-.

Once the service starts and authenticates with your Okta admin account to the Okta servers, your dashboard page will change asking you to specify what OUs in your AD you want to sync. Choose the OUs and choose your Okta username format.

In my case I’ll use UPN which is username@andreev.local, but you can choose e-mail if your have a valid e-mail specified for the users, e.g. username@google.com or the SAM account which is your login that you use for AD, e.g. username. See below.

Click Next and unless you have some non-standard AD attributes that you want to map, it’s safe to proceed with the defaults. Under the settings for the AD in Okta, you can choose the scheduled interval for the AD sync. By default, this sync is disabled. To test the integration, go to the settings page of your AD in Okta, choose Test Delegated Authentication (bottom right) and enter the username and password for an AD account that you know it’s synced with Okta.

You can also test the integration if you go to https://-company-.okta.com and log in with a synced AD user.

Okta app for AWS

Before we move to AWS part, click on Applications from the menu and click on Add Application menu. Type Amazon Web Services and select the app. Do not use AWS Console app, that’s a different one.

Click Add and you can leave the settings under General Settings or change it to AWS Console. Click Next and on the next screen, use SAML 2.0
Click on the Identity Provider Metadata link and download the file. You’ll need this for later.

Click Done and once this part is completed, we can go to AWS Console and configure AWS IAM and then come back to Okta.

AWS Console

Log to the AWS Console with an account with sufficient rights to create IAM polices, roles and users. Go to IAM and then Identity Providers on the left side. Click Create Provider and choose SAML for Provider Type, type a description (e.g. OKTA) and choose the metadata file that you’ve just downloaded.

Click on Next Step and then Create. Click on the entry that you just created and make a note of the ARN. You’ll need this later.

IAM

We’ll create two new roles based on existing AWS policies for full admin access and read only access. Go to IAM | Roles and click on Create Role. Click on SAML 2.0 federation, choose the SAML provider that we just created, select Allow programmatic and AWS Management Console access and click on Next: Permissions.

You can create your own policy if you want by clicking on Create policy or choose an existing one like I did by filtering the Read Only policies. Click on Next: Tags after.

You can tag your role and click Next: Review after…and finally you can create the role.

Do the same again IAM | Roles | SAML, but this time create a full admin role named rolFullAdminAccess (filter the policies by Administrator).
Let’s connect AWS and Okta now, but creating a user that will be able to list the roles. Go to IAM | User and click on Add user. Name your user and allow Programmatic access only.

Click on Create policy. This will open a new window. Do not close the previous one.

Click on the JSON tab and paste this policy. Then click Review policy.

{
    "Version": "2012-10-17",
    "Statement": [
        {
          "Effect": "Allow",
          "Action": [
              "iam:ListRoles",
              "iam:ListAccountAliases"
          ],
          "Resource": "*"
        }
    ]
}

Name your policy and click on Create policy.

Go back to the previous tab and click on the refresh button, right off the Create policy button. Then filter the policy and assign it. Click Next: Tags.

Proceed to create the user, but make sure you download the CSV file with the credentials for this user.

Okta – app config

Go back to Okta and click on the Sign On tab and then Edit.

Scroll down a little bit and paste your ARN value (the one that you got from AWS earlier) under Identity Provider ARN (Required only for SAML SSO. It’s under IAM | Providers | -your-provider in AWS. Click Save after.
Click on the Provisioning tab next to Sign On and click on Configure API Integration. Click the checkmark, then copy and paste the access key and the secret from the CSV file from AWS. Click Test API Credentials and if everything is OK, click on Save.

Under Provisioning make sure that Create Users and Update User Attributes are enabled.
Finally, go to the Assignments tab and select Groups. Then, click the green button Assign and choose Assign to Groups.

You will see your groups here, select the first one and click the Assign button.

You will see your roles there. Select the admin role and Save.

Do the same for the other group and role and pretty much you are all set. Open a new browser and this time log as one of the users, in my case I am logging as admin.user to https://mycompany.okta.com.

You’ll get a note that you have a new app assigned.

If you click on the app icon, you’ll get logged in to the AWS console without any passwords.

Multi-factor authentication

While the above setup looks good, you still need MFA to make things even more secure. Go to the app settings in Okta and click on the Sign On tab then click Edit.

Scroll all the way down and click on Add Rule.

Name the rule however you want and scroll all the way down.

Click on Prompt for fact and choose whatever you want from the settings.

Once configured, when you log in to your Okta dashboard, you’ll get in without prompted for MFA, but when you click on the AWS Console app, you’ll get redirected to AWS to configure your MFA. You can use the Okta mobile app for MFA or Authy which I prefer. This is because we configured the MFA to occur on the AWS level, not on Okta level.

In this article, I’ll explain how to install and configure two Windows 2019 servers running MS SQL 2017 Enterprise with AlwaysOn. The servers will have local storage only but you’ll still have HA. There are several prerequisites that you need in order to test this scenario.

– Functional AD and rights to create objects in AD
– Unrestricted traffic access between the SQL nodes and AD (you can probably restrict the ports, but do your research)
– Two AD accounts (an user account and a SQL service account)
– Two extra IPs assigned to each SQL node
– Proper DNS resolution in AWS and time synced between the nodes and DCs

Domain controllers and AD

I have two DCs running in two zones in the same region. Make sure that you can ping/resolve the servers by using only the short DNS name. E.g. My first domain controller is dc01. When I do ping dc02 from dc01, it resolves fine. If not, check the DNS settings. You should also check the advanced DNS settings. Make sure that your domain is on the top. In my case, I have the DNS settings of dc01 pointing to itself and dc02. Notice ad-domain.local on top of other suffixes. AD-DOMAIN.LOCAL is the name of my domain. If you have the DNS suffixes configured on the VPC level, you don’t have to make this change. The only thing important is that you have a proper DNS resolution.

Open up AD Users and Computers (dsa.msc) and create a single service account for the SQL servers. I’ll call it svc_sql and it should be a member of Domain Users only. The password should never expire. This account will run the SQL DB engine on SQL nodes.
Then create an OU for the cluster object. In my case, I’ll create an OU called SQLCLUSTERS.

Then create the name of your SQL cluster as a computer object and disable it.

In AD Users and Computers, under the View menu, make sure that Advanced Features is enabled. Right-click the SQL cluster computer object and choose Properties, then click on Security tab and click Add. Type the name of the service account you just created and give it Full Control.

We also need the cluster computer account to have rights to the OU. Right-click the OU that you just created, choose Properties and under the Security tab, click Advanced.
You’ll see something like this.

Click Add and in the new dialog that shows up, in the upper left corner, click the link Select a principal.

By default, computer object are not going to show up, so click on Object Types button, then check Computer and click OK to go back to the screen above.
Type the name of the SQL cluster and click on Check Names to verify it.

Click OK when it reminds you that the object is disabled. In the Permission Entry dialog box, make sure that the Type is set to Allow, and the Applies to is set to This object and all descendant objects. Finally, under Permissions, click on the Create Computer objects check box. Click OK until you close all open dialogs.

The AD part is now complete.

WSFC (Windows Server Failover Cluster)

Now, we have to create and configure the failover cluster. I have two SQL nodes, node01 and node02. We have to install WSFC on each node, but before doing that, let’s add extra two IPs per node. In AWS console, on each SQL instance, click on the network adapter, usually called eth0.

Click on the Interface ID.

Then from the Actions drop down, click on Manage IP Addresses.

Add two extra IPs per instance. You can choose DHCP provided IPs or manual. I decided to go with manual assignment. Make sure the IPs are in the same subnet as the primary and they are not in use.

For node01, I’ll use 192.168.1.60 and 192.168.1.61 and for node02 I’ll use 192.168.2.60 and 192.168.2.61. node01 and dc01 are in a 192.168.1.0/24 subnet and node02 and dc02 are in 192.168.2.0/24 subnet. Now, log to both nodes with an admin account and add the SQL service account svc_sql as a local administrator. Then log off and log back to SQL nodes as svc_sql service account.
On both nodes, install the WSFC (Windows Server Failover Cluster) from an elevated PowerShell prompt and reboot.

Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools

Once the instances come back, log as svc_sql and create the cluster. Open up an elevated command or PowerShell prompt and type cluadmin.msc (do this on one node, not both). In the wizard dialog box, click Browse and type the name of the nodes.

The cluster wizard will do some pre-checks and if everything looks good click Next.

Do not skip this part. Make sure you validate the cluster and you run all tests. It takes about a minute or two.

You’ll see some warnings about the network, but you can ignore them. This is how my report looked like. You’ll be able to enter the name of the cluster if everything is OK. In my case, the cluster name is the disabled computer object SQLCLUSTER01 that we created earlier.

Make sure you uncheck the storage setting. We are using local storage, so there is nothing to add to the cluster as a resource.

After a minute, you should get a greeting that the cluster is OK.

Back in the cluster manager, you’ll see this mess. Don’t worry.

At the bottom of the cluster manager, right click the first node and choose Properties.

How do you know which one is which? Once you open the properties, look at the Network under the General tab. Based on the subnet, you’ll have to assign the IP that belongs to that subnet. So, in my case this is how it looked like before I made the change.

I know that 192.168.2.0/24 belongs to node02, so I’ve changed the settings from DHCP to Static IP and added 192.168.2.60. Remember this IP? It was the first one that we added to node02. Scroll up if you forgot.

Do the same for the 2nd entry. This time you have to add 192.168.1.60 because the subnet is 192.168.1.0/24. Then, bring the cluster online.

Now, you can install the SQL server.

SQL Server installation

As I mentioned earlier, make sure you have correct DNS settings and the time is in sync with AD. Before you install MS SQL, make sure you have your partitions ready. They don’t have to be like this, you can use C:\ only for everything, but ask your DBA how they want to carve the space for the DB. I am using the trial version downloaded from here.

Run the installation on both nodes using the service account svc_sql. You made this a local admin, didn’t you? Click on Installation on the left side and the first option for a new SQL Server stand-alone…

Choose license.

Accept the license terms and use or do not use Microsoft Update for SQL updates.
Ignore the warning for the firewall.

Check the Database Engine Service, SQL Server Replication…

…scroll down and check Client Tools Connectivity.

Click on Named instance and type your name. In my case it’s SQL2017.

Leave the Service Accounts as is. We’ll change one of them later.

Under Server Configuration tab, use Windows authentication mode and click Add Current User.

On the Data Directories tab in the same dialog you can change the disk destinations. If you have just one C:\ partition you can skip this part. If not, map the directories here. Here are mine.

And for TempDB on the next tab in the same dialog.

Proceed to Install until the installation completes successfully.

SQL Management Tools (optional)

This step is optional. If you have SSMS already installed, you can skip this part. If not, install it on a node, both or any client workstation. From the same setup menu, install SQL Management Tools (third from the top). This will take you to a MS web site where you can download the latest SMSS (SQL Server Management Studio).

SQL service account change

Before you reboot, let’s change the account that runs SQL. This is mandatory for a SQL cluster. DO NOT change the account from the Services console, instead open SQL 2017 Configuration Manager.
Do this on both nodes. Select where it says SQL Server Services on the left and then right-click on SQL Server (SQL2017) on the right and choose Properties.
Enter the SQL service account, its password and click Apply. This will reset the SQL service and change it to run under the domain service account. Do not reboot yet.

Dynamic ports and firewall

Because we are using a named SQL instance, the DB engine assigns a random dynamic port for the listener. Instead of opening a range of ports on the firewall, we can restrict the listener to a static port and then open the firewall for that port only. Do this on both nodes. In the same SQL 2017 Configuration Manager, look for SQL Server Network Configuration on the left, expand it and select Protocols for SQL2017 or whatever you named your instance. Right-click where it says TCP/IP on the right and choose Properties.

Click on the second tab IP Addresses and scroll all the way down where it says TCP Dynamic Ports. Delete that value, leave it blank and in the next field TCP Port below, enter a random TCP port from 49152-65535. I’ll use 50000 for both nodes. You need to restart the SQL service for this change to take effect, but we’ll reboot, so no need for that. But, if you have your Windows Firewall enabled, you have to open these TCP ports. Run these command from an elevated PowerShell prompt.

New-NetFirewallRule -Name "SQL2017 Named Instance (in)" -Description "SQL2017 Named Instance" `
-DisplayName "SQL2017 Named Instance" -Enabled:True -Profile Domain,Public,Private `
-Direction Inbound -Action Allow -Protocol TCP -LocalPort 50000
New-NetFirewallRule -Name "SQL Server Rule (in)" -Description "SQL Server Rule" `
-DisplayName "SQL Rule" -Enabled:True -Profile Domain,Public,Private `
-Direction Inbound -Action Allow -Protocol TCP -LocalPort 1433
New-NetFirewallRule -Name "SQL Server Browser Rule (in)" -Description "SQL Server Browser Rule" `
-DisplayName "SQL Browser Rule" -Enabled:True -Profile Domain,Public,Private `
-Direction Inbound -Action Allow -Protocol UDP -LocalPort 1434
New-NetFirewallRule -Name "SQL Server AlwaysOn Replication (in)" -Description "SQL Server AlwaysOn Replication" `
-DisplayName "SQL Server AlwaysOn Replication" -Enabled:True -Profile Domain,Public,Private `
-Direction Inbound -Action Allow -Protocol TCP -LocalPort 5022

Now, you can reboot.

AlwaysOn

Log as the SQL service account svc_sql and open SQL Configuration Manager. You have to do this on both nodes. Similarly to what you did when you change the SQL service account, do the same.

Select SQL Server Services, right-click SQL Server (SQL2017) and check Enable AlwaysOn Availability Groups under AlwaysOn High Availability tab.

Restart the SQL service on both nodes. Once completed, open SSMS, connect to a node and create a new database.

I’ll name my database MyDB.

Make sure you backup the database. You can’t proceed without this step.

Little further below, right-click on Always On High Availability and click on New Availability Group Wizard.

Specify a name for the availability group.

Select the database that we just created.

Click on Add Replica.

Connect to node02.

I want automatic failover which means it’s a synchronous commit.

Choose Automatic Seeding.

Don’t worry about the listener.

After 10-20 seconds the configuration should complete.
Now, we need to add a listener. Expand the Availability Groups, right-click Availability Group Listeners and select Add Listener.

Give listener a name (in my case MyListener), you can choose a port (I used the default 1433, you can choose a random port but don’t forget to open the firewall) and add the other two IPs as static IPs.

Right-click the availability group and click on Show Dashboard.

Everything should be with green checkmarks and both states should be synchronized. The availability group (and the database) are configured for automatic failover, but you can do manual failover if you want. Right-click the availability group and click on Failover. This is how my manual failover looks like.

At this point you have a fully functional AlwaysOn cluster.

Test the failover (optional)

We’ll use a sample populated table to run some queries from PowerShell. Then, we’ll stop one node and watch the outcome. In order to do the test, open up SMSS, log as svc_sql and connect to the listener directly.

Click on New Query from the top.

Insert these statements. They’ll create a SQL login mapped from the domain name (in my case klimenta) and a table in the MyDB database called COLORS. Replace the values that match your domain name and the database. Execute the first part (CREATE LOGIN) on node02 too.

CREATE LOGIN [AD-DOMAIN\klimenta]  
    FROM WINDOWS  
    WITH DEFAULT_DATABASE = [MyDB];
USE MyDB;
CREATE TABLE COLORS (ID INT, NAME VARCHAR(10));
INSERT INTO COLORS VALUES(1,'RED');
INSERT INTO COLORS VALUES(2,'YELLOW');
INSERT INTO COLORS VALUES(3,'BLUE');
INSERT INTO COLORS VALUES(4,'WHITE');
GO

Double-click the login that you just created, click on User Mapping and put a checkmark next to MyDB database.

Right-click the database, choose Properties then click on Permissions. Select the username and make sure you have Connect and Select permissions.

From a separate workstation/server, you can use even the domain controller, log as the username (klimenta) that you just granted right to the MyDB database. Open up PowerShell ISE and run this script. Replace the values for the listener and the database. It’s a script that connects to the database and spits the contect of the COLORS table indefinitely. Use CTRL-C to break.

$Server = 'tcp:mylistener,1433'    
$database = 'MyDB'
$Connection = New-Object System.Data.SQLClient.SQLConnection
$Connection.ConnectionString = "server=$($Server);database=$($Database);trusted_connection=true;MultiSubnetFailover=True;"
$Connection.Open()
$Command = New-Object System.Data.SQLClient.SQLCommand
$Command.Connection = $Connection
$x=0
while ($true) {
    $Command.CommandText = 'SELECT * FROM COLORS'
    $Reader = $Command.ExecuteReader()
    $Datatable = New-Object System.Data.DataTable
    $Datatable.Load($Reader)
    $Datatable
    Start-Sleep -s 5
    Write-Host($x, "---")
    $x++;
}
$Connection.Close()  

Once you see the output, shutdown the primary node or do a manual failover. You’ll notice that there is no interruption in the program flow. The only thing that changes is the IP of the listener.

Links

YouTube (AWS)
Microsoft
PowerShell

Lately I was playing with Docker and the AWS EFS file systems and I realized that I can’t access my new NFS file system because of the DNS resolution. The reason being that I use a DNS that’s at home and this DNS has no clue about any AWS resources. This is how my setup looks like.

I have two domain controllers, DC01 and DC02. The first one is at home/on-prem and the other one is in AWS. They are on a different subnets. I also have a site-to-site VPN connection between the two. All of my resources use the DNS servers that I provide. This means that the AWS DNS that comes as default when you create a new VPC was never used. I have a specific DHCP Option Set in AWS that I use to provide my DNS servers to all of my AWS resources.

And here is the problem. When I created a new EFS file system, I tried to mount it, but my DNS had no clue where this resource is. The hostname for the EFS is not publicly resolvable. On top of that, you can’t resolve this hostname from on-prem over VPN and Direct Connect even if you use the provided AWS DNS as a forwarder. The solution before was to build a DNS server in the cloud and make it as a forwarder. As of November 2018, AWS expanded the Route 53 DNS and now you can create inbound and outbound endpoints that do this for you. In my case, I needed amazonaws.com to be resolved by my DNS. All I have to do is to create an inbound endpoint in Route 53 and tell my DNS servers to use the IPs provided by Route 53.
Here is what I did.
In Route 53, click on Inbound endpoints. Click on Create inbound endpoint. Fill out the values by specifying a name for the inbound endpoint, the VPC where your resources reside and a security group that allow access. I am not quite sure what security levels are needed here, I assume TCP/UDP 53, so I assigned a security group that gives access to all my AWS resources to the resources on-prem. Try with TCP/UDP 53 first and see if it works.

Specify two subnets and let AWS choose the IPs. These are the actual DNS server IPs that AWS will provide for you.

Click Submit. Once completed you’ll see your inbound endpoint ready.

If you click on the endpoint, you’ll see the IPs that AWS provides to you.

Now, go back to your on-prem DNS and create a conditional forwarder for amazonaws.com.

Specify the domain amazonaws.com and enter the two IPs that were provided to you.

I made sure that they are stored in AD, so both DCs can get the settings. By default, a conditional forwarder is not stored in AD, which means it won’t replicate.
Now that everything is configured, I can resolve my EFS filesystem from my on-prem server.

If you are behind a firewall and want to access some resources over SSH or RDP, most likely you won’t be able to do that. It’s because most of the corporate firewalls allow only ports 80 and 443 outbound. But you can still bypass that by tunneling everything over port 443. You will need a software called shellinabox to tunnel SSH over 443 and RDP gateway to tunnel the RDP traffic over 443. I’ll present the shellinabox solution for both CentOS 7 and FreeBSD 11. Both of these servers will be sitting somewhere in the cloud or behind your home firewall. The only requirement is to have port 443 opened and accessible on Internet. You might have a public IP or your home firewall will forward the traffic to 443, it doesn’t matter. Another option for connecting to any port is to use putty and a Linux/FreeBSD instance. I’ll describe that option last.

CentOS 7

shellinabox doesn’t come up with the default packages, so you have to install the EPEL release first.

yum install epel-release
yum install shellinabox
systemctl enable shellinaboxd

Edit the configuration file for shellinabox which is /etc/sysconfig/shellinaboxd. Make sure it looks like this.

# Shell in a box daemon configuration
# For details see shellinaboxd man page
# Basic options
USER=shellinabox
GROUP=shellinabox
CERTDIR=/var/lib/shellinabox
PORT=4200
OPTS="--css white-on-black.css -t -s /:SSH:localhost"
#OPTS="--css color.css -t -s /:SSH:localhost"

shellinabox runs on port 4200 by default. You can change it to run on 443, but you have to run as root. A better solution is to install Apache and use the mod_proxy so the Apache will listen on 443 and forward the traffic to 4200.

yum install httpd mod_ssl
systemctl enable httpd

Create the configuration file for the Apache server. In my case, I’ll access the SSH over HTTPS as sshtest.iandreev.com. Change the config below to suit your needs.

cd /etc/httpd/conf.d
touch httpd-vhosts.conf

Edit httpd-vhosts.conf and paste the following.

<VirtualHost *:443>
    SSLEngine On
    SSLCertificateFile /etc/pki/tls/certs/sshtest.iandreev.com.crt
    ServerAdmin klimenta@iandreev.com
    ServerName sshtest.iandreev.com
    ErrorLog "/var/log/httpd/sshtest.iandreev.com-error_log"
    CustomLog "/var/log/httpd/sshtest.iandreev.com-access_log" combined
    ProxyRequests On
    ProxyPreserveHost On
    <Proxy *>
        AuthUserFile /var/www/sshtest.iandreev.com/.htpasswd
        AuthName EnterPassword
        AuthType Basic
        require user ssh.admin
        Order deny,allow
        Allow from all
    </Proxy>
    ProxyPass / http://localhost:4200/
    ProxyPassReverse / http://localhost:4200/
</VirtualHost>

HTTPS requires a certificate, we’ll create a fake one. If you have a valid certificate, just put it under /etc/pki/tls/certs as sshtest.iandreev.com.crt.

cd /etc/pki/tls/certs
./make-dummy-cert sshtest.iandreev.com.crt

shellinabox when started will give you a SSH prompt so you can login to your server. A more secure solution is to protect the access even more with a username and password. Anytime you access your server, you’ll get prompted with a username and password and then you’ll get prompted with your SSH credentials.

cd /var/www
mkdir sshtest.iandreev.com
cd sshtest.iandreev.com
htpasswd -c .htpasswd ssh.admin
cd ..
chown -R apache:apache sshtest.iandreev.com

I’ve created a user called ssh.admin and the commands above will ask you for a password.
Now, it’s time to start shellinabox.

systemctl start httpd
systemctl start shellinaboxd

On a laptop behind your comporate firewall, go to https://sshtest.yourdomain.com and you should get prompted for ssh.admin’s password. Once you pass that you’ll see the login prompt in your browser. From here you can SSH to any server that has port 22 opened.
shellinabox comes with two styles. If you see above in it’s config, we provided these two lines.

OPTS="--css white-on-black.css -t -s /:SSH:localhost"
#OPTS="--css color.css -t -s /:SSH:localhost"

If you prefer black on white background, uncomment the last line, save the config file and restart shellinabox.
Depending on your CentOS install, you might have firewall and SElinux enabled. If these are not configured, shellinabox won’t work. For the firewall, you’ll have to allow port 443 inbound.

firewall-cmd --add-service=https --permanent
firewall-cmd --reload

For SElinux, you’ll have to allow Apache to make outbound connections.

/usr/sbin/setsebool -P httpd_can_network_connect 1

At the end, it will look like this.

…and this.

FreeBSD 11

We have to install Apache and shellinabox first.

pkg install shellinabox apache24

Make sure they start on boot. Add these two lines in /etc/rc.d

apache24_enable="YES"
shellinaboxd_enable="YES"
shellinaboxd_flags="--disable-ssl --css=/usr/local/www/sshtest.iandreev.com/style.css"

Go to the Apache config directory and edit the config file /usr/local/etc/apache24/httpd.conf. Make sure these lines are uncommented.

Include etc/apache24/extra/httpd-vhosts.conf
LoadModule authn_socache_module libexec/apache24/mod_authn_socache.so
LoadModule socache_shmcb_module libexec/apache24/mod_socache_shmcb.so
LoadModule ssl_module libexec/apache24/mod_ssl.so
Include etc/apache24/extra/httpd-ssl.conf
LoadModule proxy_module libexec/apache24/mod_proxy.so
LoadModule proxy_http_module libexec/apache24/mod_proxy_http.so
ServerName www.example.com:80

Go to /usr/local/etc/apache24/extra folder and make sure you have the definitiopn for the virtual host there. Change it to suit your needs.

<VirtualHost *:443>
    SSLEngine On
    SSLCertificateFile /usr/local/share/certs/sshtest.iandreev.com.crt
    SSLCertificateKeyFile /usr/local/share/certs/sshtest.iandreev.com.key
    ServerAdmin klimenta@iandreev.com
    ServerName sshtest.iandreev.com
    ErrorLog "/var/log/sshtest.iandreev.com-error_log"
    CustomLog "/var/log/sshtest.iandreev.com-access_log" combined
    ProxyRequests On
    ProxyPreserveHost On
    <Proxy *>
        AuthUserFile /usr/local/www/sshtest.iandreev.com/.htpasswd
        AuthName EnterPassword
        AuthType Basic
        require user ssh.admin
        Order deny,allow
        Allow from all
    </Proxy>
    ProxyPass / http://localhost:4200/
    ProxyPassReverse / http://localhost:4200/
</VirtualHost>

In the same directory, edit httpd-ssl.conf file and make sure it looks like this.

SSLRandomSeed startup file:/dev/urandom 512
Listen 443
SSLCipherSuite HIGH:MEDIUM:!MD5:!RC4
SSLProxyCipherSuite HIGH:MEDIUM:!MD5:!RC4
SSLHonorCipherOrder on
SSLProtocol all -SSLv3
SSLProxyProtocol all -SSLv3
SSLPassPhraseDialog  builtin
SSLSessionCache        "shmcb:/var/run/ssl_scache(512000)"
SSLSessionCacheTimeout  300

We’ll protect shellinabox with extra username (ssh.admin) and password.

cd /usr/local/www
mkdir sshtest.iandreev.com
cd sshtest.iandreev.com
htpasswd -c .htpasswd ssh.admin

We’ll need a certificate for the HTTPS site. Use your own or create a fake one. Hit ENTER for everything prompted. It’s a fake certificate.

cd /usr/local/share/certs
openssl genrsa -out sshtest.iandreev.com.key 2048
openssl req -new -key sshtest.iandreev.com.key -out sshtest.iandreev.com.csr
openssl x509 -req -days 3650 -in sshtest.iandreev.com.csr -signkey sshtest.iandreev.com.key -out sshtest.iandreev.com.crt

Unlike CentOS, FreeBSD shellinabox doesn’t come up with CSS files for the color, so we can use these two. Copy these files under /usr/local/www/sshtest.iandreev.com as blackonwhite.css and whiteonblack.css.
This is blackonwhite.css. Click to expand.

#vt100 .ansiDefR {
  color:            #ffffff;
}

#vt100 .bgAnsiDefR {
  background-color: #123450;
}

#vt100 #scrollable.inverted .ansiDefR {
  color:            #000000;
}

#vt100 #scrollable.inverted .bgAnsiDefR {
  background-color: #ffffff;
}

#vt100 .ansiDefR {
  color:            #ffdfd0;
}

#vt100 .bgAnsiDefR {
  background-color: #010203;
}

#vt100 #scrollable.inverted .ansiDefR {
  color:            #002030;
}

#vt100 #scrollable.inverted .bgAnsiDefR {
  background-color: #1f1fff;
}

This is whiteonblack.css. Click to expand.

#vt100 #cursor.bright {
  background-color: white;
  color:            black;
}

#vt100 #cursor.dim {
  background-color: black;
  opacity:          0.2;
  -moz-opacity:     0.2;
  filter:           alpha(opacity=20);
}

#vt100 #scrollable {
  color:            #ffffff;
  background-color: #000000;
}

#vt100 #scrollable.inverted {
  color:            #000000;
  background-color: #ffffff;
}

#vt100 .ansiDef {
  color:            #ffffff;
}

#vt100 .ansiDefR {
  color:            #000000;
}

#vt100 .bgAnsiDef {
  background-color: #000000;
}

#vt100 .bgAnsiDefR {
  background-color: #ffffff;
}

#vt100 #scrollable.inverted .ansiDef {
  color:            #000000;
}

#vt100 #scrollable.inverted .ansiDefR {
  color:            #ffffff;
}

#vt100 #scrollable.inverted .bgAnsiDef {
  background-color: #ffffff;
}

#vt100 #scrollable.inverted .bgAnsiDefR {
  background-color: #000000;
}

Copy one of them to be your style. Anytime you change the style, restart shellinabox.

cd /usr/local/www/sshtest.iandreev.com
cp blackonwhite.css style.css
cd ..
chown -R www:www sshtest.iandreev.com

Finally, start Apache and shellinabox.

service shellinaboxd start
service apache24 start

Access your server from a laptop behind your corporate firewall as https://sshtest.domain.com.

Windows 2016

You will need a Windows 2016 server with a public IP and port 443 allowed or you can use a Windows server behind your home network as long as port 443 is allowed. In order to bypass the RDP restriction, we’ll tunnel the RDP traffic over HTTPS using Remote Desktop Gateway.
From the Server Manager, go to Add Roles and Features. Select Remote Desktop Services.

Click Next 2-3 times and then select Remote Desktop Gateway. Click Next again and accept all the defaults. Windows will install some other components for you.
Once everything is installed, from the Server Manager’s menu click on Tools, Remote Desktop Services and then Remote Desktop Gateway Manager.
Click on the server name and in the middle pane you’ll see what you have to do.

Click on the first link, View or modify certificate properties. Choose to create a fake certificate or you can import your own. It has to be in p12 format, not PEM.

If you decide to go with a fake certificate, enter the FQDN of the server, e.g sshtest.iandreev.com. You will have to make sure that sshtest.iandreev.com resolves to the public IP of the Windows box or if you have an internal server in your home lab, then the external IP of your cable/DSL modem. Then just click on the button Create and Import Certificate, enter the FQDN sshtest.iandreev.com and then click OK when prompted. Click Apply and OK to go back.
At this point, you might want to create a user or a group that you can allow access to the Gateway.
I created a user called RDP. Back in the RD Gateway Manager, select Policies under the server name, right-click on it and choose Create New Authorization Policies. Choose the option to create both RD CAP and RD RAP policies. Here is what I did in the wizard config.

I choose BUILTIN\Users to be able to use the Gateway. The generic user RDP that I created is by default a member of the users group.

Select the default Enable device redirection for all client devices.
Check both checkmarks for Idle Timeout and Session Timeout. This is optional, but it’s good to have.
Click Next and then create the Resource Authorization Policy.

Accept the same group (BUILTIN\Users).
Choose the option at the bottom, Allow users to connect to any network resource (computer).
Choose the first option, Allow connections only to port 3389.
Click Next and Finish.
So, how do you use this solution now? Easy…
All you have to do is go to your corporate laptop and create a new RDP connection. Under the General tab enter the IP address of the Windows box that you want to reach. This is the box that listens on 3389 and that you are not able to reach directly. Mind that the Windows server that we just built is a gateway, so the Windows RD Gateway server should be able to talk to the destination server over 3389 and your corporate laptop will talk to Windows RD Gateway server over 443.

Click on the Advanced tab and then the Settings button. Select to Use these RD Gateway server settings and enter the FQDN (sshtest.iandreev.com) of the RD Gateway server that we just built.

Once you are done, click Connect and you should get prompted to enter the credentials for the RD Gateway (in my case the username and password for the RDP user) and then you’ll have to enter the username and password for the destination server.
NOTE: Make sure you use .\rdp for the username, not rdp. You can also get an error saying that the identity of the RD Gateway can’t be verified. This is most likely if you messed up the certificate and it doesn’t match the hostname. In that case, the RDP client will allow you to view the certificate. Then copy it to a file and import it on the local machine under the Trusted Root Cert Authorities.

Tunnel over putty

Let’s say that your corporate firewall allows only port 443 outbound. In this case, we’ll build a Linux/BSD server with a public IP and change the SSH listener port from 22 to 443. For this, edit sshd_config under /etc/ssh/sshd_config or /usr/local/etc/ssh/sshd_config. Look for the directive Port 22 and change it to Port 443. Restart the ssh service.
On your client machine behind the corporate firewall, open putty and under Session enter the public IP of your Linux/BSD server and port 443 so it looks like this.

Now, expand the Connection on the left side, then SSH and select Tunnels. For the source port enter 3390 and for the destination enter the IP of your Windows box where you want to connect.

Finally, save this session, open it and login to the Linux server to establish the tunnel. You should be able to run the RDP client (mstsc) and RDP to 127.0.0.1:3390.

In this post I’ll explain how to install a Chef server on CentOS 7 server. A Chef server is usually managed by a Chef workstation and the servers that we manage with the workstation via the server are called Chef nodes. For more detailed info, go to https://learn.chef.io. So, we’ll install Chef server on CentOS 7, a Chef workstation on Windows 10 and bootstrap a Chef node on CentOS 7 and a Chef node on Windows 2012R2. Then, we’ll create a cookbook that will do something and then explain a couple of commands that are commonly used. The hostnames in this post are chef-server.chef.local, chef-wks.chef.local, chef-node.chef.local for the CentOS node and chef-node-win for the Windows node.

Chef server

Go to https://downloads.chef.io/chef-server and download the RPM for Red Hat Linux. You can use the root user to install the server or some other user with sudo rights. Once the RPM file has been transferred, install the server.

cd
sudo rpm -Uvh chef-server-core-12.17.15-1.el7.x86_64.rpm

Most likely, you’ll file-name will differ because Chef releases updates quite often.
Once installed, do an initial configuration.

sudo chef-server-ctl reconfigure

We need to create an admin user for Chef. This admin users is a Chef user, not an OS user.

sudo chef-server-ctl user-create chef-admin Chef Admin chefadmin@iandreev.com SomePassword --filename chef-admin.pem

This command will create an admin user called chef-admin with first name Chef and last name Admin. The e-mail of the chef-admin user is chefadmin@iandreev.com and the password is SomePassword. The command will also create a certificate that we will use to log to the server from the workstation. So, the PEM file is very important. If everything is OK, you’ll get your prompt back without any notifications.
Now that we have the user created, we’ll create an organization. An organization is a top-level entity for the roles, groups and nodes. With the same command, we’ll add the user that we just created as a member of the organization.

sudo chef-server-ctl org-create chef-org "Chef Organization, Inc." --association_user chef-admin --filename chef-org.pem

This command creates a Chef organization called chef-org, a detailed description for the organization is “Chef Organization, Inc.” and we associate the user chef-admin with the organization. The PEM file is used for validation as well, but we won’t need it. It was used in versions of Chef before v12 to authenticate users. Make sure that the organization’s name is all lower case, otherwise you’ll get an error.
At this point, we have the user and the organization created. This should be enough to do everything we need, but we’ll install a GUI called Chef Manage that can ease some of the admin tasks.

sudo chef-server-ctl install chef-manage 

Once installed, we have to accept the license. Type yes and hit Enter when prompted.

sudo chef-manage-ctl reconfigure

Once completed, you can access the server over https (e.g. https://chef_server_name_or_ip). Use the same username and password from the above. It looks like this.

We are done with the server.

Chef workstation

Chef servers are managed from workstations. We’ll use Windows 10. The installation is very simple. Go to this link and download the client (Chef DK – Development Kit) for Windows 10. Use the defaults to install. Once installed, you’ll see a shortcut on your desktop.

This will start PowerShell in admin mode. If your workstation was never configured for PowerShell, you’ll see something like this.

Type:

Set-ExecutionPolicy RemoteSigned

and say Y and enter.
Close the window and open it again. This time you’ll be greeted with Ohai, welcome to ChefDK.
OK, so now we have the client installed, but how do we talk to the server? We need some sort of a home folder where all of our cookbooks, recipes and config files will be stored. I’ll use a folder called chef that’s under the Documents folder for this.

cd ~\Documents
mkdir -p chef\.chef

We created another subfolder .chef, where we’ll keep our certificate. That’s the certificate that we generated when we created the chef-admin user. Let’s copy that file from the server to the workstation. Mind that the user username in the command below is the user that I’ve used to run the Chef install. If you used root to install the Chef server, replace the username with root.

scp username@chef-server:~username/chef-admin.pem chef/.chef/chef-admin.pem

This command will add the Chef server (hostname: chef-server) to the list of known hosts under C:\users\\.ssh folder and copy the certificate PEM file under C:\users\\Documents\chef\.chef folder. Let’s create a folder where we’ll store our cookbooks.

cd ~\Documents\chef
mkdir cookbooks

Now, create a file called knife.rb with the following content and save it under chef\.chef folder. Or, if you have the Chef Manage GUI, you can download the same file if you go to Administration from the menu, then select your Organization and then Generate Knife Config from the left side-bar.

current_dir = File.dirname(__FILE__)
log_level                 :info
log_location              STDOUT
node_name                 "chef-admin"
client_key                "#{current_dir}/chef-admin.pem"
chef_server_url           "https://chef-server.chef.local/organizations/chef-org"
cookbook_path             ["#{current_dir}/../cookbooks"]

Under the chef\.chef folder, you should have two files now: chef-admin.pem certificate and knife.rb config file. Let’s verify if we are all set now.

cd ~\Documents\chef
knife ssl fetch

You should see something like this. This will import the nginx server certificate to your local cert store.

WARNING: Certificates from chef-server.chef.local will be fetched and placed in your trusted_cert
directory (c:\users\kliment.andreev\documents\chef\.chef\trusted_certs).

Knife has no means to verify these are the correct certificates. You should
verify the authenticity of these certificates after downloading.

Adding certificate for chef-server_chef_local in c:\users\kliment.andreev\documents\chef\.chef\trusted_certs/chef-server_chef_local.crt

OK. Then, check.

cd ~\Documents\chef
knife ssl check

It should say something like this.

Connecting to host chef-server.chef.local:443
Successfully verified certificates from `chef-server.chef.local'

This is also a good sign that everything works fine. Sometimes ssl fetch and ssl check pass, but this one fails. In that case, make sure that the node_name directive in knife.rb is your actual chef-admin name.

cd ~\Documents\chef
knife client list

The output should be something like chef-org-validator. If you noticed, I used cd ~\Documents\chef a lot. Chef is kind of picky, so it is important to know where are you in the folder tree when running the commands. Always make sure you are in your home directory, cd ~\Documents\chef before running the knife and chef commands.

Configure git

Before we generate our first cookbook, we’ll have to configure git. Do that with the following commands.

git config --global user.email "you@example.com"
git config --global user.name "Your Name"

Test cookbook

Without going into any explanations, we’ll create a test cookbook, upload it to the server and then list the server for available cookbooks.

cd ~\Documents\chef
chef generate cookbook cookbooks/test
knife cookbook upload test
knife cookbook list

If the output looks like this, you are OK.

PS C:\Users\Kliment.ANDREEV\documents\chef> chef generate cookbook cookbooks/test
Generating cookbook test
- Ensuring correct cookbook file content
- Committing cookbook files to git
- Ensuring delivery configuration
- Ensuring correct delivery build cookbook content
- Adding delivery configuration to feature branch
- Adding build cookbook to feature branch
- Merging delivery content feature branch to master

Your cookbook is ready. Type `cd cookbooks/test` to enter it.

There are several commands you can run to get started locally developing and testing your cookbook.
Type `delivery local --help` to see a full list.

Why not start by writing a test? Tests for the default recipe are stored at:

test/smoke/default/default_test.rb

If you'd prefer to dive right in, the default recipe can be found at:

recipes/default.rb

PS C:\Users\Kliment.ANDREEV\documents\chef> knife cookbook upload test
Uploading test         [0.1.0]
Uploaded 1 cookbook.

PS C:\Users\Kliment.ANDREEV\documents\chef> knife cookbook list
test   0.1.0

PS C:\Users\Kliment.ANDREEV\documents\chef>

Chef node

From the workstation execute this line to install the node.

knife bootstrap chef-node --ssh-user username --sudo -N chef-node.chef.local

Use a username that can su as root, otherwise the command will fail. You have to enter the password twice. Once for the username prompt and the second time for the sudo. The output should look like this. Click to expand.

Creating new client for chef-node.chef.local
Creating new node for chef-node.chef.local
Connecting to chef-node
username@chef-node's password:
chef-node 
chef-node We trust you have received the usual lecture from the local System
chef-node Administrator. It usually boils down to these three things:
chef-node 
chef-node     #1) Respect the privacy of others.
chef-node     #2) Think before you type.
chef-node     #3) With great power comes great responsibility.
chef-node 
chef-node knife sudo password: 
Enter your password: 
chef-node 
chef-node -----> Installing Chef Omnibus (-v 13)
chef-node downloading https://omnitruck-direct.chef.io/chef/install.sh
chef-node   to file /tmp/install.sh.2931/install.sh
chef-node trying wget...
chef-node el 7 x86_64
chef-node Getting information for chef stable 13 for el...
chef-node downloading https://omnitruck-direct.chef.io/stable/chef/metadata?v=13&p=el&pv=7&m=x86_64
chef-node   to file /tmp/install.sh.2944/metadata.txt
chef-node trying wget...
chef-node sha1   037a61a5d9c89d9b71d4c4f6256f45ed422a73ee
chef-node sha256 18826690ac2c7e5f16a21d898ed77be7d78fd2d84bc2a71b4506ee480876bc4b
chef-node url    https://packages.chef.io/files/stable/chef/13.6.4/el/7/chef-13.6.4-1.el7.x86_64.rpm
chef-node version        13.6.4
chef-node downloaded metadata file looks valid...
chef-node downloading https://packages.chef.io/files/stable/chef/13.6.4/el/7/chef-13.6.4-1.el7.x86_64.rpm
chef-node   to file /tmp/install.sh.2944/chef-13.6.4-1.el7.x86_64.rpm
chef-node trying wget...
chef-node Comparing checksum with sha256sum...
chef-node Installing chef 13
chef-node installing with rpm...
chef-node warning: /tmp/install.sh.2944/chef-13.6.4-1.el7.x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID 83ef826a: NOKEY
chef-node Preparing...                                                            (1################################# [100%]
chef-node Updating / installing...
chef-node    1:chef-13.6.4-1.el7                                                  ( ################################# [100%]
chef-node Thank you for installing Chef!
chef-node Starting the first Chef Client run...
chef-node Starting Chef Client, version 13.6.4
chef-node resolving cookbooks for run list: []
chef-node Synchronizing Cookbooks:
chef-node Installing Cookbook Gems:
chef-node Compiling Cookbooks...
chef-node [2018-01-20T08:33:15-08:00] WARN: Node chef-node.chef.local has an empty run list.
chef-node Converging 0 resources
chef-node 
chef-node Running handlers:
chef-node Running handlers complete
chef-node Chef Client finished, 0/0 resources updated in 08 seconds

Windows requires port 5985 (WinRM) to be opened, so make sure you allow this port, especially if the Chef server and the Chef Windows node are not in the same domain. To test the connection, do:

knife wsman test chef-node-win --manual-list

The output should be like this.

Connected successfully to chef-node-win at http://node-win:5985/wsman.

For some reason, I wasn’t able to install Chef node on Windows using an admin account that I’ve created. I was getting authentication errors. Once I used the built-in Administrator account, everything went fine. This is how to install Chef on Windows.

knife bootstrap windows winrm chef-node-win.chef.local --winrm-user Administrator --winrm-password MyPassword -N node-win.chef.local

And if everything is OK, you’ll see the output. Click to expand.

Creating new client for chef-node-win.chef.local
Creating new node for chef-node-win.chef.local

Waiting for remote response before bootstrap.chef-node-win.chef.local . 
chef-node-win.chef.local Response received.
Remote node responded after 0.0 minutes.
Bootstrapping Chef on chef-node-win.chef.local
chef-node-win.chef.local Rendering "C:\Users\ADMINI~1\AppData\Local\Temp\bootstrap-35815-1516539477.bat" chunk 1 
chef-node-win.chef.local Rendering "C:\Users\ADMINI~1\AppData\Local\Temp\bootstrap-35815-1516539477.bat" chunk 2 
chef-node-win.chef.local Rendering "C:\Users\ADMINI~1\AppData\Local\Temp\bootstrap-35815-1516539477.bat" chunk 3 
chef-node-win.chef.local Rendering "C:\Users\ADMINI~1\AppData\Local\Temp\bootstrap-35815-1516539477.bat" chunk 4 
chef-node-win.chef.local Rendering "C:\Users\ADMINI~1\AppData\Local\Temp\bootstrap-35815-1516539477.bat" chunk 5 
chef-node-win.chef.local Rendering "C:\Users\ADMINI~1\AppData\Local\Temp\bootstrap-35815-1516539477.bat" chunk 6 
chef-node-win.chef.local Rendering "C:\Users\ADMINI~1\AppData\Local\Temp\bootstrap-35815-1516539477.bat" chunk 7 
chef-node-win.chef.local Rendering "C:\Users\ADMINI~1\AppData\Local\Temp\bootstrap-35815-1516539477.bat" chunk 8 
chef-node-win.chef.local Checking for existing directory "C:\chef"...
chef-node-win.chef.local Existing directory not found, creating.
chef-node-win.chef.local 
chef-node-win.chef.local C:\Users\Administrator>(
chef-node-win.chef.local echo.url = WScript.Arguments.Named("url")  
chef-node-win.chef.local  echo.path = WScript.Arguments.Named("path")  
chef-node-win.chef.local  echo.proxy = null  
chef-node-win.chef.local  echo.'* Vaguely attempt to handle file:// scheme urls by url unescaping and switching all  
chef-node-win.chef.local  echo.'* / into .  Also assume that file:/// is a local absolute path and that file://<foo>  
chef-node-win.chef.local  echo.'* is possibly a network file path.  
chef-node-win.chef.local  echo.If InStr(url, "file://") = 1 Then  
chef-node-win.chef.local  echo.url = Unescape(url)  
chef-node-win.chef.local  echo.If InStr(url, "file:///") = 1 Then  
chef-node-win.chef.local  echo.sourcePath = Mid(url, Len("file:///") + 1)  
chef-node-win.chef.local  echo.Else 
chef-node-win.chef.local  echo.sourcePath = Mid(url, Len("file:") + 1)  
chef-node-win.chef.local  echo.End If  
chef-node-win.chef.local  echo.sourcePath = Replace(sourcePath, "/", "\")  
chef-node-win.chef.local  echo. 
chef-node-win.chef.local  echo.Set objFSO = CreateObject("Scripting.FileSystemObject")  
chef-node-win.chef.local  echo.If objFSO.Fileexists(path) Then objFSO.DeleteFile path  
chef-node-win.chef.local  echo.objFSO.CopyFile sourcePath, path, true  
chef-node-win.chef.local  echo.Set objFSO = Nothing  
chef-node-win.chef.local  echo. 
chef-node-win.chef.local  echo.Else 
chef-node-win.chef.local  echo.Set objXMLHTTP = CreateObject("MSXML2.ServerXMLHTTP")  
chef-node-win.chef.local  echo.Set wshShell = CreateObject( "WScript.Shell" )  
chef-node-win.chef.local  echo.Set objUserVariables = wshShell.Environment("USER")  
chef-node-win.chef.local  echo. 
chef-node-win.chef.local  echo.rem http proxy is optional  
chef-node-win.chef.local  echo.rem attempt to read from HTTP_PROXY env var first  
chef-node-win.chef.local  echo.On Error Resume Next  
chef-node-win.chef.local  echo. 
chef-node-win.chef.local  echo.If NOT (objUserVariables("HTTP_PROXY") = "") Then  
chef-node-win.chef.local  echo.proxy = objUserVariables("HTTP_PROXY")  
chef-node-win.chef.local  echo. 
chef-node-win.chef.local  echo.rem fall back to named arg  
chef-node-win.chef.local  echo.ElseIf NOT (WScript.Arguments.Named("proxy") = "") Then  
chef-node-win.chef.local  echo.proxy = WScript.Arguments.Named("proxy")  
chef-node-win.chef.local  echo.End If  
chef-node-win.chef.local  echo. 
chef-node-win.chef.local  echo.If NOT isNull(proxy) Then  
chef-node-win.chef.local  echo.rem setProxy method is only available on ServerXMLHTTP 6.0+  
chef-node-win.chef.local  echo.Set objXMLHTTP = CreateObject("MSXML2.ServerXMLHTTP.6.0")  
chef-node-win.chef.local  echo.objXMLHTTP.setProxy 2, proxy  
chef-node-win.chef.local  echo.End If  
chef-node-win.chef.local  echo. 
chef-node-win.chef.local  echo.On Error Goto 0  
chef-node-win.chef.local  echo. 
chef-node-win.chef.local  echo.objXMLHTTP.open "GET", url, false  
chef-node-win.chef.local  echo.objXMLHTTP.send() 
chef-node-win.chef.local  echo.If objXMLHTTP.Status = 200 Then  
chef-node-win.chef.local  echo.Set objADOStream = CreateObject("ADODB.Stream")  
chef-node-win.chef.local  echo.objADOStream.Open 
chef-node-win.chef.local  echo.objADOStream.Type = 1  
chef-node-win.chef.local  echo.objADOStream.Write objXMLHTTP.ResponseBody  
chef-node-win.chef.local  echo.objADOStream.Position = 0  
chef-node-win.chef.local  echo.Set objFSO = Createobject("Scripting.FileSystemObject")  
chef-node-win.chef.local  echo.If objFSO.Fileexists(path) Then objFSO.DeleteFile path  
chef-node-win.chef.local  echo.Set objFSO = Nothing  
chef-node-win.chef.local  echo.objADOStream.SaveToFile path  
chef-node-win.chef.local  echo.objADOStream.Close 
chef-node-win.chef.local  echo.Set objADOStream = Nothing  
chef-node-win.chef.local  echo.End If  
chef-node-win.chef.local  echo.Set objXMLHTTP = Nothing  
chef-node-win.chef.local  echo.End If 
chef-node-win.chef.local ) 1>C:\chef\wget.vbs 
chef-node-win.chef.local 
chef-node-win.chef.local C:\Users\Administrator>(
chef-node-win.chef.local echo.param( 
chef-node-win.chef.local  echo.   [String] $remoteUrl,  
chef-node-win.chef.local  echo.   [String] $localPath  
chef-node-win.chef.local  echo.) 
chef-node-win.chef.local  echo. 
chef-node-win.chef.local  echo.$ProxyUrl = $env:http_proxy;  
chef-node-win.chef.local  echo.$webClient = new-object System.Net.WebClient;  
chef-node-win.chef.local  echo. 
chef-node-win.chef.local  echo.if ($ProxyUrl -ne '') {  
chef-node-win.chef.local  echo.  $WebProxy = New-Object System.Net.WebProxy($ProxyUrl,$true)  
chef-node-win.chef.local  echo.  $WebClient.Proxy = $WebProxy  
chef-node-win.chef.local  echo.} 
chef-node-win.chef.local  echo. 
chef-node-win.chef.local  echo.$webClient.DownloadFile($remoteUrl, $localPath); 
chef-node-win.chef.local ) 1>C:\chef\wget.ps1 
chef-node-win.chef.local 
chef-node-win.chef.local C:\Users\Administrator>(
chef-node-win.chef.local  
chef-node-win.chef.local   
chef-node-win.chef.local  
chef-node-win.chef.local ) 
chef-node-win.chef.local Detected Windows Version 6.3 Build 9600
chef-node-win.chef.local 
chef-node-win.chef.local C:\Users\Administrator>goto Version6.3 
chef-node-win.chef.local 
chef-node-win.chef.local C:\Users\Administrator>goto Version6.2 
chef-node-win.chef.local 
chef-node-win.chef.local C:\Users\Administrator>goto architecture_select 
chef-node-win.chef.local 
chef-node-win.chef.local C:\Users\Administrator>IF "AMD64" == "x86" IF not defined PROCESSOR_ARCHITEW6432 
chef-node-win.chef.local 
chef-node-win.chef.local C:\Users\Administrator>goto install 
chef-node-win.chef.local Checking for existing downloaded package at "C:\Users\ADMINI~1\AppData\Local\Temp\chef-client-latest.msi"
chef-node-win.chef.local No existing downloaded packages to delete.
chef-node-win.chef.local Attempting to download client package using PowerShell if available...
chef-node-win.chef.local powershell.exe -ExecutionPolicy Unrestricted -InputFormat None -NoProfile -NonInteractive -File  C:\chef\wget.ps1 "https://www.chef.io/chef/download?p=windows&pv=2012&m=x86_64&DownloadContext=PowerShell&v=13" "C:\Users\ADMINI~1\AppData\Local\Temp\chef-client-latest.msi"
chef-node-win.chef.local Download via PowerShell succeeded.
chef-node-win.chef.local Installing downloaded client package...
chef-node-win.chef.local 
chef-node-win.chef.local C:\Users\Administrator>msiexec /qn /log "C:\Users\ADMINI~1\AppData\Local\Temp\chef-client-msi20931.log" /i "C:\Users\ADMINI~1\AppData\Local\Temp\chef-client-latest.msi" 
chef-node-win.chef.local Successfully installed Chef Client package.
chef-node-win.chef.local Installation completed successfully
chef-node-win.chef.local Writing validation key...
chef-node-win.chef.local Validation key written.
chef-node-win.chef.local 
chef-node-win.chef.local C:\Users\Administrator>mkdir C:\chef\trusted_certs 
chef-node-win.chef.local 
chef-node-win.chef.local C:\Users\Administrator>(
chef-node-win.chef.local echo.-----BEGIN CERTIFICATE-----  
chef-node-win.chef.local  echo.MIID6zCCAtOgAwIBAgIBADANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEQ 
chef-node-win.chef.local  echo.MA4GA1UECgwHWW91Q29ycDETMBEGA1UECwwKT3BlcmF0aW9uczEbMBkGA1UEAwwS 
chef-node-win.chef.local  echo.Y2hlZi5hbmRyZWV2LmxvY2FsMB4XDTE4MDExNDIyMjkwMloXDTI4MDExMjIyMjkw 
chef-node-win.chef.local  echo.MlowUTELMAkGA1UEBhMCVVMxEDAOBgNVBAoMB1lvdUNvcnAxEzARBgNVBAsMCk9w 
chef-node-win.chef.local  echo.ZXJhdGlvbnMxGzAZBgNVBAMMEmNoZWYuYW5kcmVldi5sb2NhbDCCASIwDQYJKoZI 
chef-node-win.chef.local  echo.hvcNAQEBBQADggEPADCCAQoCggEBAKiyl7i+TpCdwvWtAnpcktKL5BKm/zonS87f 
chef-node-win.chef.local  echo.mm61beXd7CDJifcpllinq/b/96r6872odbmVYHZ3uwGhX3+95AlFOOZiM+Ze08Ds 
chef-node-win.chef.local  echo.574Rj53Xz+ASSCcZsbwdAPc//dBs67GndNjgH3iy2bAFxjOkPJJX9bBZoKhYEXRp 
chef-node-win.chef.local  echo.9xEdUEQwj3W0g92b3sDx2gDSOXgP43g+vqRLjUiCAmRmCmgFkMkb9Xitxn3CXXiM 
chef-node-win.chef.local  echo.KDSUDiR1CA8FbrzIZ/O4ahB9UMeGvUEUkD2nN3BcWphXYWz5sVxxVBlqmyK51EIa 
chef-node-win.chef.local  echo.lUd/lKw0xw2iYPUAkjxPdr7djJGgEQqXiYC3/r4v4w3RAdVY5jUCAwEAAaOBzTCB 
chef-node-win.chef.local  echo.yjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBT+SJ3clvJyuQqFPpcaCWX7QB8i 
chef-node-win.chef.local  echo.HzAdBgNVHREEFjAUghJjaGVmLmFuZHJlZXYubG9jYWwweQYDVR0jBHIwcIAU/kid 
chef-node-win.chef.local  echo.3JbycrkKhT6XGgll+0AfIh+hVaRTMFExCzAJBgNVBAYTAlVTMRAwDgYDVQQKDAdZ 
chef-node-win.chef.local  echo.b3VDb3JwMRMwEQYDVQQLDApPcGVyYXRpb25zMRswGQYDVQQDDBJjaGVmLmFuZHJl 
chef-node-win.chef.local  echo.ZXYubG9jYWyCAQAwDQYJKoZIhvcNAQELBQADggEBAImSEMXEX+rqbRd3ireoFbkY 
chef-node-win.chef.local  echo.b97RmbsXjcwmA6MuAIZIyoFw/DwRUBrahrlLhXEAgeDWPlgS2xGniLJxdGx5a0ca 
chef-node-win.chef.local  echo.pz/8hC4RQuIq4kOWhkvcFTms/hPXIVSyBcYEt4FFkrhOeIDxwoBrEfIFncXC8DiL 
chef-node-win.chef.local  echo.IdPUH1DZeJLx8T7zCrUjFpPG3IL65HXIsteXaGNsJtKoRdDprPIIGlUlw72n5M9Y 
chef-node-win.chef.local  echo.Y8VoH6s5roky3OemhOIqPzgK/fVhY3cQWivRdDNe7M2hT03TmwpvbFs0Emydaa+Q 
chef-node-win.chef.local  echo.E+QroZpUvQZK6I6gtN1kG5K8M+HBNnx2NavKj8YjuQokeJYEF6Fb7dhGz5BMgPU=  
chef-node-win.chef.local  echo.-----END CERTIFICATE----- 
chef-node-win.chef.local ) 1>C:\chef/trusted_certs/chef_andreev_local.crt 
chef-node-win.chef.local 
chef-node-win.chef.local C:\Users\Administrator>(
chef-node-win.chef.local echo.chef_server_url  "https://chef.andreev.local/organizations/iandreev"  
chef-node-win.chef.local  echo.validation_client_name "chef-validator"  
chef-node-win.chef.local  echo.file_cache_path   "c:/chef/cache"  
chef-node-win.chef.local  echo.file_backup_path  "c:/chef/backup"  
chef-node-win.chef.local  echo.cache_options     ({:path => "c:/chef/cache/checksums", :skip_expires => true})  
chef-node-win.chef.local  echo.node_name "chef-node-win.chef.local"  
chef-node-win.chef.local  echo.log_level        :info  
chef-node-win.chef.local  echo.log_location       STDOUT  
chef-node-win.chef.local  echo.trusted_certs_dir "c:/chef/trusted_certs" 
chef-node-win.chef.local ) 1>C:\chef\client.rb 
chef-node-win.chef.local 
chef-node-win.chef.local C:\Users\Administrator>(echo.{"run_list":[]}) 1>C:\chef\first-boot.json 
chef-node-win.chef.local Starting chef to bootstrap the node...
chef-node-win.chef.local 
chef-node-win.chef.local C:\Users\Administrator>SET "PATH=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\ruby\bin;C:\opscode\chef\bin;C:\opscode\chef\embedded\bin" 
chef-node-win.chef.local 
chef-node-win.chef.local C:\Users\Administrator>chef-client -c c:/chef/client.rb -j c:/chef/first-boot.json 
chef-node-win.chef.local Starting Chef Client, version 13.6.4
chef-node-win.chef.local 
chef-node-win.chef.local [2018-01-21T07:58:38-05:00] INFO: *** Chef 13.6.4 ***
chef-node-win.chef.local [2018-01-21T07:58:38-05:00] INFO: Platform: x64-mingw32
chef-node-win.chef.local [2018-01-21T07:58:38-05:00] INFO: Chef-client pid: 2936
chef-node-win.chef.local [2018-01-21T07:58:38-05:00] INFO: The plugin path C:\chef\ohai\plugins does not exist. Skipping...
chef-node-win.chef.local [2018-01-21T07:58:49-05:00] INFO: Setting the run_list to [] from CLI options
chef-node-win.chef.local [2018-01-21T07:58:49-05:00] INFO: Run List is []
chef-node-win.chef.local [2018-01-21T07:58:49-05:00] INFO: Run List expands to []
chef-node-win.chef.local [2018-01-21T07:58:49-05:00] INFO: Starting Chef Run for chef-node-win.chef.local
chef-node-win.chef.local [2018-01-21T07:58:49-05:00] INFO: Running start handlers
chef-node-win.chef.local [2018-01-21T07:58:49-05:00] INFO: Start handlers complete.
chef-node-win.chef.local [2018-01-21T07:58:49-05:00] INFO: Error while reporting run start to Data Collector. URL: https://chef.andreev.local/organizations/iandreev/data-collector Exception: 404 -- 404 "Not Found"  (This is normal if you do not have Chef Automate)
chef-node-win.chef.local resolving cookbooks for run list: []
chef-node-win.chef.local [2018-01-21T07:58:49-05:00] INFO: Loading cookbooks []
chef-node-win.chef.local Synchronizing Cookbooks:
chef-node-win.chef.local Installing Cookbook Gems:
chef-node-win.chef.local Compiling Cookbooks...
chef-node-win.chef.local [2018-01-21T07:58:49-05:00] WARN: Node chef-node-win.chef.local has an empty run list.
chef-node-win.chef.local Converging 0 resources
chef-node-win.chef.local 
chef-node-win.chef.local [2018-01-21T07:58:50-05:00] INFO: Chef Run complete in 0.437135 seconds
chef-node-win.chef.local 
chef-node-win.chef.local Running handlers:
chef-node-win.chef.local [2018-01-21T07:58:50-05:00] INFO: Running report handlers
chef-node-win.chef.local Running handlers complete
chef-node-win.chef.local [2018-01-21T07:58:50-05:00] INFO: Report handlers complete
chef-node-win.chef.local Chef Client finished, 0/0 resources updated in 11 seconds

Check the details for each node.

knife node show chef-node.chef.local
Node Name:   chef-node.chef.local
Environment: _default
FQDN:        chef-node.chef.local
IP:          192.168.1.16
Run List:    
Roles:       
Recipes:     
Platform:    centos 7.2.1511
Tags:    

    
knife node show chef-node-win.chef.local
Node Name:   chef-node-win.chef.local
Environment: _default
FQDN:        chef-node-win
IP:          192.168.1.20
Run List:    
Roles:       
Recipes:     
Platform:    windows 6.3.9600
Tags:        

In this post, I’ll explain how to configure a rsyslog server and client on various operating systems. For the servers, I’ll chose 2 Red Hat 7 servers and the clients will be AWS Linux, FreeBSD and Windows 2016.
rsyslog is an open-source utility for logging, a derivate of the original syslog. As defined by RFC 3164, each message includes the facility code and severity level.

The severity levels are these. (Both screenshots are from Wikipedia).

RHEL 7 rsyslog servers

RHEL 7 comes with rsyslog installed by default. Make sure it’s running.

systemctl status rsyslog

The configuration file is /etc/rsyslog.conf. Make sure that these lines are uncommented. They tell the rsyslog daemon to accept TCP and UDP connections.

# Provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

# Provides TCP syslog reception
$ModLoad imtcp
$InputTCPServerRun 514

If you make changes in /etc/rsyslog.conf, make sure you verify the config.

rsyslogd -N 1

If you make a change, you’ll have to restart the rsyslog daemon.

systemctl restart rsyslog

To test if rsyslog works fine, try a test.

logger -p local0.notice -t from_cmd_line "Test Message"

If you check the /var/log/messages, a file where by default rsyslog writes the output, you’ll see the message.

tail /var/log/messages

OK, so we didn’t have to make any changes on both RHEL servers. Let’s move to the clients.
NOTE: If you have firewalld enabled, you’ll have to open the ports for the clients.

firewall-cmd --permanent --zone=public --add-port=514/tcp
firewall-cmd --permanent --zone=public --add-port=514/udp
firewall-cmd --reload

AWS Linux, RHEL 6, CentOS 6

AWS Linux is based on RHEL 6 so the instructions will apply for all of them. Check if rsyslog is running.

service rsyslog status

Edit /etc/rsyslog.conf and make sure these lines are commented. We don’t want a server, we want a client.

# Provides UDP syslog reception
#$ModLoad imudp
#$UDPServerRun 514

# Provides TCP syslog reception
#$ModLoad imtcp
#$InputTCPServerRun 514

Add these lines (11 to 14) somewhere at the end.

#$WorkDirectory /var/lib/rsyslog # where to place spool files
#$ActionQueueFileName fwdRule1 # unique name prefix for spool files
#$ActionQueueMaxDiskSpace 1g   # 1gb space limit (use as much as possible)
#$ActionQueueSaveOnShutdown on # save messages to disk on shutdown
#$ActionQueueType LinkedList   # run asynchronously
#$ActionResumeRetryCount -1    # infinite retries if host is down
# remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional
#*.* @@remote-host:514
# ### end of the forwarding rule ###

*.*     @@10.0.0.170
$ActionExecOnlyWhenPreviousIsSuspended on
& @@10.0.0.225
$ActionExecOnlyWhenPreviousIsSuspended off

# Finally include all config files in /etc/rsyslog.d. This allows overrides
# of the default configuration above.
$IncludeConfig /etc/rsyslog.d/*.conf

These four lines means that my primary rsyslog server has an IP of 10.0.0.170 and in case it’s not reachable, use the server 10.0.0.225. Line 11 tells the rsyslog client to log everything to the server. If you want only certain messages logged, than you can change it, e.g. instead of *.* @@10.0.0.170 you can use something like *.info @@10.0.0.170 or *.info;auth.err @@10.0.0.170. Look at those two tables above. If you run this command on the client.

logger -p local0.notice -t from_aws_linux "Test Message"

and do

tail -f /var/log/messages

on the server, you’ll see the message on the server, not on the client.

FreeBSD

FreeBSD uses the old syslog, not rsyslog, but we can still redirect the logs to our RHEL servers. Edit /etc/syslog.conf and all the way at the end add this line.

*.* @10.0.0.170

As you can see, syslog uses one @, not two @@s. Restart the service and send a test message. You’ll see that the message goes to the RHEL server now.

service syslogd restart
logger -p local0.notice -t from_FreeBSD "Test Message"

Windows

Go to this link and download the rsyslog client. You can see the link for the download and also for the manual.

The rsyslog agent for Windows is very detailed and requires some studying. Use the manual, there are some examples there. I’ll show you how to forward the event ID 7036. This event gets triggered when a service changes its state. So, download the client and open up the GUI. Expand the following and click on Rsyslog. Enter the primary and secondary rsyslog server’s IPs. Click Save in the upper left corner and then click Restart.

If you check the logs on your rsyslog server, you’ll see a lot of logging going on. Pretty much everything that Windows does. We just want to filter all these logs to a single event ID.
So, in the Default Rule Set, click Filters, then right-click AND, choose Add Filter, Event Log Monitor and then Event ID.

Enter the Event ID 7036, click Save and Restart.

Now, go to Services (services.msc) and restart Windows Update service. You should see this on the rsyslog server.

A public key infrastructure (PKI) is a set of roles, policies, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates and manage public-key encryption. That’s what Wikipedia says.
Today, using certificates is a must. Google search gives you better search scores if your web site is using certificates and if your site is mobile-friendly. So, in this post I’ll describe how to deploy an Enterprise PKI on Windows 2016 server. This post is mostly for on-prem deployments, but it will give you some insights on how PKI works. I will create one Windows IIS web server joined to the domain and one Linux server (not joined to the domain) running Apache. I’ll create SSL sites on both and deploy the certificates, so the clients (Windows machines on your corp domain) won’t get that certificate warning when browsing these site.
In order to do what we planed, we’ll use Active Directory Certificate Services (AD CS). We’ll create a lab with a domain controller, an offline Certificate Authority, an Enterprise Certificate Authority and two web servers. These two web servers (one running IIS and the other running Apache) will host two web sites (test1 and test2) that will have SSL certificates issued by our CA.
The hostnames are :

• dc01.empire.local
• offCA
• entCA.empire.local
• iis.empire.local
• apache

Domain Controller(s)

I won’t explain how to create a domain controller. Just make sure you have a domain controller(s) in your environment. My domain is called empire.local with EMPIRE as a NetBIOS domain name.

Offline Root Certificate Authority

Why do we need an offline Certificate Authority and enterprise CA? It’s per MS best practices. The offline CA will be the one that holds the PKI, but once it’s configured it can be brought offline. The actual certificates will be signed by the enterprise CA. In case the enterprise CA gets compromised, you’ll have to bring the offlince CA on-line and revoke the certificate for the enterprise CA.
So, let’s build the offline CA. This server shouldn’t be part of the domain. Leave it as a workgroup member. From the Server Manager, click on Add Roles and Features.

Select Active Directory Certificate Services.

Under role services, select Certification Authority.

Once the installation is completed, click on the flag icon in the upper right corner to configure the CA.

Choose the defaults or if you want a separate local user, specify it here. You have to create that user first.

Choose to configure Certification Authority.

Choose Standalone CA.

Choose Root CA.

Select to Create a new private key.

Choose SHA256 and 2048. Don’t use SHA1, it’s being deprecated.

Choose the common name for the CA. In my case it’s ROOT-CA.

Use validity for this CA. I used 10 instead of the default 5.

Choose where the database and the logs will be located. I used the defaults, best practice is to use a separate data drive.

Verify everything looks good and click Configure.

Once completed, go to C:\Windows\System32\CertSrv\CertEnroll. This is where you’ll have the root certificate (offCA_ROOT-CA.crt) and the Certificate Revocation List (ROOT-CA.crl).

Go to the Administrative Tools under Control Panel and run the Certification Authority.

Now, we have to configure the Root (offline) CA so it is aware of the subordinate (enterprise) CA. Right click the name of the CA, choose Properties and then click on the Extensions tab. You’ll see something like this.

Click Add and enter the following in the Location field. Then click OK. Don’t click Insert.

http://entCA.empire.local/certdata/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

Replace entCA.empire.local with the name of your subordinate (enterprise) server.
After you click OK, check these two checkmarks.

By default, they are not checked. Click Apply and you’ll be prompted to restart the CA service. Go back to the properties of the Root CA, click on the Extensions tab, but this time switch to Authority Information Access (AIA) instead of CRL Distribution Point (CDP).

Same thing here. Click Add and enter the following in the Location field.

http://entCA.empire.local/certdata/<ServerDNSName><CaName><CertificateName>.crt

Replace entCA.empire.local with your enterprise CA server name. Click OK, don’t click Insert.

Then check Include in the AIA extension of issues certificates which by default is not checked. Click OK and that will restart the CA service.
Select Revoked Certiicates, right-click, choose All Tasks and then Publish.

Click OK for the New CRL.

If you go back to C:\Windows\System32\CertSrv\CertEnroll, you’ll see that the time stamp on ROOT-CA.crl file has changed.
Now, we need the root certificate (without the private key) exported so we can copy it to the enterprise CA. Right-click the CA, choose Properties and from the General tab, choose View Certificate.

Click on Details tab and then Copy to File.

In the Certificate Export Wizard, choose the first option (DER).
Click Next and save it under c:\windows\system32\certsrv\certenroll with a name something like this.

Click Save then Finish.

Enterprise (standalone) Certificate Authority

Now, let’s move to the subordinate (enterprise) CA. This is the server that will actually issue and revoke certificates. Make sure this server is a member of the domain.
From the server manager go to Add Roles and Features.

Choose Active Directory Certificate Services.

Choose both, Certification Authority and Certificate Authority Web Enrollment.

Web enrollment will require IIS. Choose defaults.

Once the installation is completed, click on the flag icon in the upper right corner to configure the CA.

Choose the Administrator or some other domain user if you want.

Select the Certification Authority and Certification Authority Web Enrollment.

Select Enterprise CA.

Select Subordinate CA.

Create a new Private key.

Choose SHA256 and 2048.

Choose the common name. In my case it’s ENT-CA.

Choose where to save the request file. This will have to be signed by the Root CA.

Choose defaults. Again, best practice is to save it to a separate data drive.

Verify and click Configure.

You’ll see this warning. This means you have to sign the request file that we just saved under C:\

Now, copy the files from the Root CA (the first server) to Enterprise CA (this server). You will need to copy those three files under C:\Windows\System32\CertSrv\CertEnroll to anywhere on the Enterprise CA server. Choose the desktop, we won’t need them after the configuration. Right click on the certificate file that we created (the one with NO-PVT-KEY in its name) in its name and a .cer as a file extenstion. Click on Install Certificate.

Choose Local Machine.

Choose Place all certificates in the following store.

Click Browse and select Trusted Root Certification Authority.

Click Next and Finish.
Now, go to c:\inetpub\wwwroot\ and create a folder certdata. Remember when we created the CDP and IAI extensions? We used something like http://entCA.empire.local/certdata… Well, we are creating that now. So, create that folder and move the other two files there.

OK, now go back to the offline Root CA. Copy the request file that was created when we installed CA on the Enterprise CA. That’s the file that’s on the C:\ drive of the Enterprise CA. Move it to the desktop of the offline Root CA.
Launch the Certification Authority (Control Panel, Administrative Tools, Certification Authority) and select the name of the Root CA. Right-click, select All Tasks and then Submit New Request.

Browse to the file that we just copied on the desktop.

Click on Pending Requests. You’ll see our request is waiting for approval.

Select the requested item on the right and then right-click, All Tasks and Issue.

The request entry will be gone, but if you click on Issued Certificates, you’ll see the certificate there.

Double-click the certificate on the right and then click on Details tab.

Click Copy to File. In the export wizard choose this option.

Save it on the desktop. I named it as entCA-signed, which will remind me that this is a signed certificate for the Enterprise CA.

Go back to the Enterprise CA and copy this entCA-signed file to the desktop. Then start the Certification Authority (Control Panel, Administrative Tools, Certification Authority). You will see that the CA service is stopped. Right click the enterprise CA name, choose All Tasks and then Install CA Certificate.

Browse to that file entCA-signed that we just copied from the offline Root CA.

Once imported, start the service from the toolbar (green triangle icon). The service should start successfully.

At this point we have to tell the domain controller that there is a new Enterprise CA in the environment. Log to the domain controller, and copy the file (ROOT-CERT-NO-PVT-KEY) from the Enterprise CA. I saved this file on the desktop on Enterprise CA, so do the same. Copy the file from the desktop of Enterprise CA to the desktop of the domain controller. On the domain controller, go to Control Panel, Administrative Tools, then Group Policy Management.
Expand the GP to edit the default domain policy.

Right-click and Edit. Go to Computer Configuration, Policies, Windows Settings, Security Settings, Public Key Policies and Trusted Root Certification Authorities. Right click on it and choose Import.

Local machine is automatically selected.

Choose the certificate, the one without private key.

The Certificate Import Wizard will launch.

Make sure this is where the certificate will be stored.

Click Finish.

OK, what now? First, delete the files that you don’t need. The ones on the desktop of the Enterprise CA, the domain controller and the offline CA. and the request file on the c:\drive on the Enterprise CA. You can also shut down offline CA. it’s not needed for another 10 years.

IIS Windows Web Server

OK, so we have the PKI in place, but let’s build an IIS web server that uses certificates, which means it will listen on port 443. This web server will be a member of a domain and the URL will be test1.empire.local. Users will access the site as https://site1.empire.local.
Log in to the IIS server and install IIS. This server must be a member of the domain. From the Server Manager add the IIS role.

Create a folder called test1.empire.local under c:\inetpub\wwwroot. Create a text file called index.txt and type something.

Rename the index.txt as index.html.
Start the Internet Information Services (IIS) Manager from Control Panel, Administrative Tools or click on Start then type inetmgr. Right-click on Sites and choose Add Website.

Configure it and click OK.

Once the site is started, make sure that you have the test1.empire.local in the DNS, so the client computers know that test1.empire.local resolves to an IP.

From any machine that’s on the domain, go to http://test1.empire.local. Make sure it works.

Go back to the IIS server. Click on the IIS server name and double-click Server Certificates.

Click on Create Domain Certificate on the right side.

In the dialog box that shows up, fill out the values. The common name is the actual server name.

Click the Select button and specify our Enterprise CA. If you don’t see anything in the certification Authority box when you click Select, it means that the IIS server doesn’t know about the Enterprise CA because the default domain policy is not present. Try with gpforce /update first, to update the domain policy.

Click Finish.
If everything goes according to the plan, you’ll see that you have your certificate issued.

Now, click on the actual web site that we created and click on Bindings on the right-side.

Click on Add button and fill out the values. Pretty much we are telling IIS that we want an SSL site that runs on port 443 with a certificate that we already got from the Enterprise CA.

Now, go back to any client on the network and browse to https://test1.empire.local. You’ll see this.

If you click on the lock icon in the address bar, you’ll see that we got the certificates right.

Apache Web Server

I’ll build a web server running Apache in the environment. I won’t go into details how to do that. Each flavor of Linux/*BSD has its own way of doing it. I’ll use AWS Linux which is based on Red Hat 6. It really doesn’t matter what you use, as long as you know how to configure Apache. Make sure you have the URL in the DNS, e.g. test2.empire.local to resolve to some IP.
For instructions on how to configure Apache on AWS/RHEL6/CentOS 6, you can check my post. For RHEL 7/CentOS chek this link and for FreeBSD use this one.
First, we have to generate the private key for the server. I’ll put it under /etc/certs directory.Do this by typing:

mkdir /etc/certs
cd /etc/certs
openssl genrsa -out test2.empire.local.key 2048

Then we’ll generate a request file that the Enterprise CA will have to sign.

openssl req -new -key test2.empire.local.key -out test2.empire.local.csr

You’ll be prompted to fill out the blanks, similarly with what we did with the IIS server.

Remember, common name is the name of your server URL.
Once you execute these two commands, you’ll have two files under /etc/certs. The private key and the the certificate signing request (.csr extension means that).

The Enterprise CA will have to sign the request file and issue a certificate.
Issuing this certificate is a little bit different. Go to the Enterprise CA and using a browser go to http://localhost/certsrv.

Click on Request a certificate. Then click on advanced certificate request.

Click on the second line, Submit a certificate…

On the Linux/BSD server, open up the csr file under /etc/certs with your favorite editor (vi, nano, vim). It’s just a text file.

Select the text, copy it to the clipboard and paste it under Saved Request field.

For the Certificate Template, choose the Subordinate Certification Authority and click Submit.

Select Base 64 encoded and then you can download the certificate or the certificate chain by clicking the link. In my case, I’ll download the certificate only.

Save the file somewhere on the desktop (delete after use), edit it with notepad, select all and copy. This is how it looks like.

Go back to your Linux/BSD server and edit a new file under /etc/certs. I’ll name my file test2.empire.local.crt, so I know that this is a server certificate. Paste the text from notepad and save it. Edit the httpd.conf or httpd-vhosts.conf or whatever file you have for your web server and create an entry for your web site. In my case it looks like this.

<VirtualHost *:443>
    SSLEngine on
    SSLCertificateFile /etc/certs/test2.empire.local.crt
    SSLCertificateKeyFile /etc/certs/test2.empire.local.key
    ServerAdmin darth.vader@empire.local
    DocumentRoot /var/www/test2.empire.local
    ServerName test2.empire.local
    ErrorLog logs/test2.empire.local-error_log
    CustomLog logs/test2.empire.local-access_log common
</VirtualHost>

Go to the root of your web site, in my case it’s /var/www/test2.empire.local and create an index.html (not .htm) file with something in it.

Finally, go to https://test2.empire.local and you should see the site.

norem for Linux/*BSD

A small utility written in Bourne shell (compatible with both sh and bash, which means works without changes on all *BSD/Linux) that strips comments from a source file. E.g. I am too lazy to scroll through /etc/ssh/sshd_config file to look for any valid directives.
Here is /etc/ssh/sshd_config on FreeBSD.

#       $OpenBSD: sshd_config,v 1.98 2016/02/17 05:29:04 djm Exp $
#       $FreeBSD: releng/10.3/crypto/openssh/sshd_config 296853 2016-03-14 13:05:13Z des $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

# Note that some of FreeBSD's defaults differ from OpenBSD's, and
# FreeBSD has a few additional options.

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

# The default requires explicit activation of protocol 1
#Protocol 2

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 1024

# Ciphers and keying
#RekeyLimit default none

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin no
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#RSAAuthentication yes
#PubkeyAuthentication yes

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
#AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# Change to yes to enable built-in password authentication.
#PasswordAuthentication no
#PermitEmptyPasswords no

# Change to no to disable PAM authentication
#ChallengeResponseAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# Set this to 'no' to disable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
#UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation sandbox
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum FreeBSD-20160310

# no default banner path
#Banner none

# override default of no subsystems
Subsystem       sftp    /usr/libexec/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#       X11Forwarding no
#       AllowTcpForwarding no
#       PermitTTY no
#       ForceCommand cvs server

With this utility, I can just do:

norem -f /etc/ssh/sshd_config

… and voila…You have the meat without the bones.

Subsystem       sftp    /usr/libexec/sftp-server

Almost all *nix utilities have “#” as a comment, but some languages such as Java and C++ use “//” for comments. In this case, we have to run:

norem -f file -c "/"

The utility is not smart enough for multi-line comments such as “/*…*/”
Here is the source:

#!/bin/sh

usage()
{
    echo "usage: norem [-f file ] | [-c char] | [-e]] | [-h]]"
    echo "Prints a file skipping the lines that start with -c"
    echo "By default empty lines are not printed, use -e yes to include them"
    echo "Kliment Andreev - 2016"
}

if [ "$#" == "0" ]; then
        usage
        exit 1
fi

while [ $# -gt 0 ]; do
        key="$1"

        case $key in
                -f|--file)
                        FILENAME="$2"
                    shift
                        ;;
        -c|--char)
                        CHARACTER="$2"
                        shift
                ;;
                -e|--empty)
                EMPTY="$2"
                shift
                ;;
        *)
                usage
                        exit
                ;;
        esac
        shift
done

if [ -z "${CHARACTER}" ]; then
        CHARACTER="#"
fi

if [ -z "${EMPTY}" ]; then
        cat ${FILENAME} | sed "/^\\${CHARACTER}/d" | awk /./
else
        cat ${FILENAME} |sed "/^\\${CHARACTER}/d"
fi

norem for PowerShell

The same utility for PowerShell. The input parameters are the same.

Param(
	[string]$fileName,
	[string]$char="#",
	[string]$empty
)

function usage {
    Write-Host "usage: norem [-f file ] | [-c char] | [-e]]"
    Write-Host "Prints a file skipping the lines that start with -c"
    Write-Host "By default empty lines are not printed, use -e yes to include them"
    Write-Host "Kliment Andreev - 2016"
}

if ($psboundparameters.Count -eq 0) {
    usage
    exit
}

if ($empty.ToUpper().Contains("Y")) {
    Get-Content $fileName | Where { $_ -notmatch "^" + $char }
}
else {
    Get-Content $fileName | Where { $_ -notmatch "^" + $char } | Where {$_.trim() -ne ""}
}

Here is a quick way to install Terminal server on 2012R2 and specify your license server. Actually, it’s called Remote Desktop services server and Remote Desktop services license server.

Click on Add Roles and Features Wizard. Specify Remote Desktop Services installation.

Select Quick Start.

Select Session-based desktop deployment.

Make sure it’s the right server and click Next.

Click on Restart the destination server automatically if required.

Wait for the process to complete.

Once completed, click on RD Licensing and then from the Tasks drop down, click on Edit Deployment Properties.

Choose the licensing mode, type the license server name, click Add and OK.

Recently, we moved to CommVault for backing up VMs. We use a CommVault solution that interacts with NetApp for taking snaps. Once the backup runs, it time-stamps the VM with the last backup taken. If you don’t need an e-mail in HTML format with the report, remove the lines from 103 to 113. Finally, remove the comment line # from line 57 if you want the report on the screen.

Based on this info, I made a script that loops through all clusters and VMs and dumps the report in a mail. You can remove lines 5 to 14 if you don’t want the script scheduled.

# PowerCLI script that lists all VMs under clusters that start with USCORPROD*
# and prints the Last Backup attribute from CommVault
# If the difference between the run time of the script and the last backup is
# more than $HoursDifference, write the output with red color
Add-PSSnapin VMware.VimAutomation.Core
Add-PSSnapin VMware.VimAutomation.Vds
if(get-item HKLM:\SOFTWARE\Microsoft\PowerShell\1\PowerShellSnapIns\VMware.VimAutomation.Core){
	. ((get-item HKLM:\SOFTWARE\Microsoft\PowerShell\1\PowerShellSnapIns\VMware.VimAutomation.Core).GetValue("ApplicationBase")+"\Scripts\Initialize-PowerCLIEnvironment.ps1")
}
else
{
	write-warning "PowerCLI Path not found in registry, please set path to Initialize-PowerCLIEnvironment.ps1 manually. Is PowerCli aleady installed?"
	. "D:\Programs (x86)\VMware\Infrastructure\vSphere PowerCLI\Scripts\Initialize-PowerCLIEnvironment.ps1"
}

# Specify the vCenter server
$server = "vcenter"
# Specify the difference in hours to compare
$HoursDifferenceCompare = 24
# Cluster filter
$ClusterFilter = "*"
# Connect to vCenter
Connect-VIServer -Server $server -user domain\username -password vcpassword
# Initalize the main HTML content
$midHTML=""
# Get each cluster that starts with $ClusterFilter and sort them. 
# Make sure only unique values are returned
ForEach ($Cluster in Get-Cluster $ClusterFilter | Sort -unique)
{
	# Get all the VMs per cluster
	$VMs = Get-Cluster $Cluster | Get-VM 
	# Loop each VM
	ForEach ($VM in $VMs)
	{
		# Get the last backup attribute
		$LastBackup = Get-VM $VM | Get-Annotation -CustomAttribute "Last Backup"
		# Parse the output, trinm the string
		$LastBackupTimeStamp = $LastBackup -replace "Last Backup:"
		# Get the date/time when the script started
		$StartDate=(Get-Date)
		# The end date is the Last Backup time for the VM
		# If the VM was never backed up, assume 01/01/70
		if ($LastBackupTimeStamp -eq '') {
			$EndDate = [datetime]'January 1, 1970'
			$LastBackupTimeStamp = "NEVER"}
		else {
			$EndDate = [datetime]$LastBackupTimeStamp 
			}
		# Calculate the difference
		$TimeSpan = New-TimeSpan -Start $StartDate -End $EndDate
		# It's a negative value, so get the absolute
		$DaysDifference = [math]::abs($TimeSpan.Days)
		$HoursDifference = [math]::abs($TimeSpan.Hours) + ($DaysDifference * 24)
		# Print the output
		if ($HoursDifference -gt $HoursDifferenceCompare) {
			# Remove for debugging if needed
			#Write-Host $Cluster " " $VM " " $LastBackupTimeStamp
			# Build the HTML
			$midHTML = $midHTML + '<font color="red">'
			$midHTML = $midHTML + "<p>" + $Cluster + " " + $VM.Name.PadRight(30,"-") + " " + $LastBackupTimeStamp + "</p>"
			$midHTML = $midHTML + "</font>"
		} else {
			$midHTML = $midHTML + "<p>" + $Cluster + " " + $VM.Name.PadRight(30,"-") + " " + $LastBackupTimeStamp + "</p>"
		}
	}	
}

# Top HTML header
$topHTML = @"
<!DOCTYPE html>
<html>
<body>
<font face="Courier New, Courier, monospace">
<style>
p
{
  margin:0;
  padding:0;
  font-size:12px;
    line-height:12px;
}
div
{
  margin:0;
  padding:0;
}
</style>
<div>
<p>&#160;&#160;&#160;CLUSTER NAME&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;SERVER NAME&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;DATE OF LAST BACKUP</p>
<p>-----------------------------------------------------------------------</p>
"@

# Bottom HTML footer
$bottomHTML = @"
<p>-----------------------------------------------------------------------</p>
<p>Script by K.Andreev - 20160630</p>
</div>
</font>
</body>
</html>
"@

# e-mail setup
$EmailFrom ="sender@domain.com"
$EmailTo ="receiver@domain.com"
$msg = New-Object System.Net.Mail.MailMessage ($EmailFrom,$EmailTo)
$msg.subject = "CommVault Report " + $StartDate
$msg.IsBodyHtml = $true;
$msg.Body =$topHTML + $midHTML + $bottomHTML
$smtpClient = New-Object System.Net.Mail.SmtpClient
$smtpClient.Host = "smtp.server.com"
$smtpClient.EnableSsl = $false
$smtpClient.Send($msg)

# Disconnect from vCenter
Disconnect-VIServer -Server $Server -Confirm:$false