Month: May 2019

Would you like to build a new Windows EC2 server in Amazon AWS, and then join it to Stanford’s Active Directory domain?  You could do things like allow your users to log in using their SUNet IDs (i.e. WIN\[sunet]), or maybe you want to apply Group Policy Objects to your servers.  University IT is very close to being able offer AD in the Cloud, a project being led by Stanford’s Windows Infrastructure team.   

Our team, the Technology Consulting Group (TCG), helped with some testing.  TCG’s testing was done in a non-production AD environment, so the details below are subject to change.  However, here’s a quick overview for those that are interested.  Simply stated, there are two key requirements…

First off, IPv6: 

Traffic from your Windows server to the Domain Controllers is only allowed over IPv6, so you need to enable it within AWS.  Plus, for security reasons the Windows Infrastructure group has firewall rules in place, so they will need to explicitly grant your server access.  Here are the steps we used. 

• Enable IPv6 at the VPC level (you will probably get assigned a /56 static range of IPs)
• Next, out of that new /56 IPv6 range, assign a smaller /64 range to the AWS subnet where your Windows server will live. 
• Give this /64 range to the Windows team.  They will add “permit” rules to their Domain Controller firewalls. 
• Finally, go to your EC2 Windows instance and allow AWS to auto-assign an IPv6 address.  (This IP will be in addition to the private, and possibly public, IPv4 address(es) already in use by your machine) 

Next, IPSec Tunnel:

All traffic to/from the DCs must be encrypted.  To do so, your EC2 instance needs to create an IPSec tunnel using a UIT provided certificate.  Fortunately, the Windows Infrastructure team has a couple of PowerShell scripts to make this task very easy, and are located here:  https://code.stanford.edu/winfra/aws-ad-client/tree/master/scripts

• First run this one:   

 ./Get-VaultCertificate.ps1  -vault_role_id "xxxxxxxxxxxxxxxxxxxx" -vault_secret_id "yyyyyyyyyyyyyyyyyy"  

This script reaches out to Stanford’s “Vault” system, and then using special ID values provided to you, it grabs a new certificate and installs it onto your EC2 machine in the Windows certificate store.

• Then run:   

./New-MemberIPSecPolicy.ps1 -remote_ipscope "xyz:xyz:xyz:xyz::/56"

This one creates a new IPSec tunnel on your Windows EC2 instance.  It uses the above certificate and sets up an IPSec rule for traffic to the DCs.  (The specific /56 range for the DCs will be provided to you by the Windows team as well.)

Then you are done!  At this point, you can simply join your Windows server to the Stanford AD domain like you normally would, and then you can log into your Windows sever using your AD account!

Being a System Engineer has never been easy to begin with.  You have to be well versed in technologies and constantly keeping up with the latest and greatest and keep updating your skillset.  However, to be an All Star System Engineer, you almost need a PhD degree in Psychology and speak multi-languages.

Although I am half kidding on the PhD in Psychology and speak multiple languages part, it’s really not too far from the truth.  A successful System Engineer must be able to implement technologies to help solve problems, at the same time, he/she must be able deal with the clients in order to fully understand their needs.  A good System Engineer should be a good listener who don’t always put their ideas before the client’s. A good System Engineer first listens to the client, gathers the information, pauses and digests the information, and then keeps listening.  It’s not possible to solve a problem without first finding out what the problem is. Too many people are very quick to jump to conclusion and start offering solutions. Often times, it’s as simple as listening attentively, that would make the client feel they are heard and it would save a lot of going back-and-forth.  If you don’t get anything else out of this article, just remember one word, “LISTEN.”

Another thing that a good System Engineer does really well is to be empathetic.  They don’t undermine what the client is telling them and what they must be going through.  The client comes to us with an issue. To us, the issue could be very minor or at least not a big deal (not the-end-of-the-world kind of big).  But to the client, it could be very stressful and anxiety provoking. We need to be mindful of that. We should first acknowledge that there’s an issue that the client is experiencing.  Understand their frustration or any anxiety that they might be having as the result of the incident. Assure them that we are on it. Come up with a game plan on how you would tackle the issue and share it with the client.  Give the client sufficient and frequent updates so that they know that you are working on it. When you think you have resolved the issue, be sure to check with the client to make sure that they are aware that the issue is resolved.  Have them test it before closing the case.

A good System Engineer should keep in mind that techies and the general end users don’t really speak the same language.  More often than not, general users are more likely to understand Martian than the technical mumbo jumbo that we’re accustomed to speaking in the IT world.  When communicate with clients, we need to watch out for the kind of language that we use in our message. Keep in mind that the client may not know what you mean by GB, TB, AD, FQDN, AZ’s, VPC’s, etc.  In client communication, we have to cater our message to the specific client. Some clients may be more technically savvy than others. In which case, you can use more of the technical language. However, for the ones that are more technically challenged, we have to keep in mind to use simpler plain English.  Be ready to do a little bit of handholding and a whole lot of translation to try to get your point across.

In summary, to be a good System Engineer requires good technical skills.  That’s almost a given. However, to be a great System Engineer, you have to be a good listener, and at the same time, to be empathetic to the clients in order to truly understand what the clients need.  Try to use plain English instead of technical jargons in communication with clients. If you’re able to speak their language and see things from their perspectives, you can win them over and gain their trust.  If you can do that, you’ve won half of the battle and well on your way to a successful relationship!