These are the tools i use pretty much every day, so i thought i would share them and where to get them from:
(click on the name to be taken to the download page)
Remote Server Administration Tools
Install these on your Windows 7 Client, within the turn windows features on or off feature in control panel, a new option called "remote server administration tools" will exist. install this to get tools such as Active Directory Users and Computers, Hyper-V Manager etc
Putty
A great SSH, Telnet and console client all in one
Remote Desktop Connection Manager
If you manage a lot of servers via RDP, this tool is a god send. you can add multiple computers to one console, and group them into different roles, you can also right click on an entire group of servers (e.g. Domain Controllers) and log into them all at once. Many clicks are saved!
Notepad ++
Does what it says on the tin. if you edit any kind of code (XML etc) this is essential
ImgBurn
Although Windows 7 has burning features built in, it still lacks some of the required functionality. This tool has a tiny footprint, some great functionality and some cool sound effects!
Monday, 27 September 2010
Thursday, 23 September 2010
Installing a System Centre Essentials 2010 agent manually
You may come into a situation where you need to manually install the SCE agent, here is how.
Run setupsce.exe and click on install essentials agent
Specify the FQDN of your SCE server, and the management group name (by default this is SCEServername_mg)
You will also need the update services SSL certificate and the code signing certificate, you can find these on the SCE server in:
C:\program files\system center essentials\certificates
Copy these to the PC you are installing the agent on, and then browse to them in the installer setup window.
Once the agent is successfully installed, it will need to be manually approved in the SCE management console
Launch the SCE management console and select the administration section, then expand device management | pending management
Under pending management, you should see a section called “Manual Agent Install”, simply right click on the computer listed and click approve
Your agent should now check in.
Run setupsce.exe and click on install essentials agent
Specify the FQDN of your SCE server, and the management group name (by default this is SCEServername_mg)
You will also need the update services SSL certificate and the code signing certificate, you can find these on the SCE server in:
C:\program files\system center essentials\certificates
Copy these to the PC you are installing the agent on, and then browse to them in the installer setup window.
Once the agent is successfully installed, it will need to be manually approved in the SCE management console
Launch the SCE management console and select the administration section, then expand device management | pending management
Under pending management, you should see a section called “Manual Agent Install”, simply right click on the computer listed and click approve
Your agent should now check in.
Labels:
sce,
system centre essentials,
windows
Wednesday, 22 September 2010
SAN Certificates – a great way to get more for your money
When it comes to SSL certificates, you have two choices, go for a standard SSL certificate for a single domain, or get a wildcard cert for *.yourdomain.com
I’ve always been a fan of wildcard certificates; I believe in the long run these are cheaper as a single certificate will cater for all of your SSL needs; however wildcard certificates come at a price.
When using IIS or ISA/TMG you have the ability to host multiple domains on a single IP address or Web listener using host headers, however this only applies to HTTP traffic. When using SSL only one SSL certificate can be applied to an IP address.
This causes a problem, do you apply lots of different IP addresses to your web server or ISA/TMG server and use a certificate for each domain, or do you buy a wildcard certificate.
In the environment I work in, we are able to get certificates for pennies, but this doesn’t cover wildcard certificates. This means its difficult to justify a wildcard certificate.
However, there is a way! You can create what is known as “Subject Alternative Name” certificates. This is just like a normal certificate, but it is valid for any other domain you specify.
For example, I could request a SAN cert for:
Webmail.yourdomain.com
Portal.yourdomain.com
Crm.yourdomain.com
Anythingelseyouwant.yourdomain.com
To request a SAN cert, open an mmc and add the certificates snap in to it (ensure you select local computer)
Expand Certificates | Personal | Certificates
Right click on certificates and select All Tasks | Advanced Operations | Create custom request
Click next on the first two prompts, then select the web server template and click next.
Click the details button to expand the web server certificate template, and then click properties.
Add the normal subject names such as Organisation and country. Then add as many common names (domains) as you like!
Follow the rest of the wizard until completion; you will then have a CSR to upload to your certificate provider. This certificate will be valid for all of the domains you specified. If you think far enough in the future and specify some domains you think you may need in the future, it will save even more money!
I’ve always been a fan of wildcard certificates; I believe in the long run these are cheaper as a single certificate will cater for all of your SSL needs; however wildcard certificates come at a price.
When using IIS or ISA/TMG you have the ability to host multiple domains on a single IP address or Web listener using host headers, however this only applies to HTTP traffic. When using SSL only one SSL certificate can be applied to an IP address.
This causes a problem, do you apply lots of different IP addresses to your web server or ISA/TMG server and use a certificate for each domain, or do you buy a wildcard certificate.
In the environment I work in, we are able to get certificates for pennies, but this doesn’t cover wildcard certificates. This means its difficult to justify a wildcard certificate.
However, there is a way! You can create what is known as “Subject Alternative Name” certificates. This is just like a normal certificate, but it is valid for any other domain you specify.
For example, I could request a SAN cert for:
Webmail.yourdomain.com
Portal.yourdomain.com
Crm.yourdomain.com
Anythingelseyouwant.yourdomain.com
To request a SAN cert, open an mmc and add the certificates snap in to it (ensure you select local computer)
Expand Certificates | Personal | Certificates
Right click on certificates and select All Tasks | Advanced Operations | Create custom request
Click next on the first two prompts, then select the web server template and click next.
Click the details button to expand the web server certificate template, and then click properties.
Add the normal subject names such as Organisation and country. Then add as many common names (domains) as you like!
Follow the rest of the wizard until completion; you will then have a CSR to upload to your certificate provider. This certificate will be valid for all of the domains you specified. If you think far enough in the future and specify some domains you think you may need in the future, it will save even more money!
Configuring shibboleth IdP to talk to an Active Directory
For those of you implementing a shibboleth IdP in an Active Directory environment, here is how the login.config and LDAP configuration within attribute-resolver.xml should look
When implementing our IdP I found lots of conflicting information on how it should be setup, we run a Windows Server 2008 R2 forest and domain functional level where all domain controllers are also global catalogues. I can confirm these settings work:
LDAP configuration in attribute-resolver.xml
<!-- Example LDAP Connector -->
<resolver:DataConnector id="myLDAP" xsi:type="LDAPDirectory" xmlns="urn:mace:shibboleth:2.0:resolver:dc"
ldapURL="ldap://domain.suffix:3268" baseDN="dc=domain,dc=suffix" principal="idpserviceaccount@domain.suffix"
principalCredential="passwordgoeshere">
<FilterTemplate>
<![CDATA[
(samAccountName=$requestContext.principalName)
]]>
</FilterTemplate>
</resolver:DataConnector>
LDAP authentication configuration in login.config
When implementing our IdP I found lots of conflicting information on how it should be setup, we run a Windows Server 2008 R2 forest and domain functional level where all domain controllers are also global catalogues. I can confirm these settings work:
LDAP configuration in attribute-resolver.xml
<!-- Example LDAP Connector -->
<resolver:DataConnector id="myLDAP" xsi:type="LDAPDirectory" xmlns="urn:mace:shibboleth:2.0:resolver:dc"
ldapURL="ldap://domain.suffix:3268" baseDN="dc=domain,dc=suffix" principal="idpserviceaccount@domain.suffix"
principalCredential="passwordgoeshere">
<FilterTemplate>
<![CDATA[
(samAccountName=$requestContext.principalName)
]]>
</FilterTemplate>
</resolver:DataConnector>
// Example LDAP authentication
// See: https://spaces.internet2.edu/display/SHIB2/IdPAuthUserPass
edu.vt.middleware.ldap.jaas.LdapLoginModule required
host="domain.suffix"
base="dc=domain,dc=suffix"
port="3268"
userField="sAMAccountName"
subtreeSearch="true"
serviceUser="serviceaccount@domain.suffix"
ServiceCredential="passwordgoeshere";
// See: https://spaces.internet2.edu/display/SHIB2/IdPAuthUserPass
edu.vt.middleware.ldap.jaas.LdapLoginModule required
host="domain.suffix"
base="dc=domain,dc=suffix"
port="3268"
userField="sAMAccountName"
subtreeSearch="true"
serviceUser="serviceaccount@domain.suffix"
ServiceCredential="passwordgoeshere";
Labels:
active directory,
idp,
opensource,
shibboleth
Wednesday, 15 September 2010
Shibboleth IdP – Getting the eduPersonScopedAffiliation attribute from Active Directory using security groups
I have implemented a Shibboleth IdP which authenticates users against our Server 2008 R2 forest and domain functional level Active Directory
We are a member of the UK Access Management Federation for Education and Research, which require the following attributes to be available:
eduPersonScopedAffiliation: user's organisational affiliation
eduPersonTargetedID: persistent user pseudonym for personalisation
eduPersonPrincipalName: persistent user id across multiple services
eduPersonEntitlement: extensible list of URIs for extra properties
Using the attribute-resolver.xml file, eduPersonPrincipalName is linked to the sAMAccountName attribute in our directory service, and the eduPersonEntitlement is linked to an extension attribute in the directory. eduPersonTargetedID is a computed value using the objectGUID attribute in our directory and encrypted using a salt.
eduPersonScopedAffiliation is an interesting one. Originally we had planned to link it to another extension attribute in the directory, and reconfigure our management tool to add the staff or student value as well as the member value to the attribute. This worked as long as there was only one entry specified in the extension attribute, as soon as we tried any number of different combinations of staff and member for example, the attribute wasn’t released.
After extensive research and trying different methods I came up with, I contacted the UK federation service desk. They are really great guys and worked relentlessly to find a solution to our problem. Specifically Sara and Steve (thanks to the both of you!)
We found a script (link below) which will generate the eduPersonScopedAffiliation based on OU. This in most cases would be ideal (specify the students OU and the staff OU) unfortunately our directory structure doesn’t separate staff and students by OU (not my design!) therefore this would not work.
Never the less here is the link
What we do have, is a security group for staff, and a security group for students. Steve decided he would use the script as a template and modify it to look at groups instead. Steve made a good start and handed over to Sara when he went on vacation.
We were having problems getting the script to see the group membership, we come across this document which detailed how someone else had setup the eduPersonScopedAffiliation, although it wasn’t what we needed, it turned out their syntax was pretty useful and Sara go the script working!
This script looks for group membership that CONTAINS the specified words. Therefore your security groups only need to contain the words you specify.
The users need to be an explicit member of the group, unfortunately it doesn’t work for nested groups, however the script is pretty simple to expand by copying and pasting, so If you had two groups you wanted to use, instead of nesting them into one main group, just specify them both in the script.
The first step is to uncomment the eduPersonAffiliation attribute, this will be used as a source attribute for the eduPersonScopedAfailiation attribute and is where the script magic happens. It should be as follows:
<resolver:AttributeDefinition xsi:type="Script" xmlns="urn:mace:shibboleth:2.0:resolver:ad"
id="eduPersonAffiliation">
id="eduPersonAffiliation">
<!-- Dependency that provides the source attribute. -->
<resolver:Dependency ref="myLDAP" />
<resolver:Dependency ref="myLDAP" />
<!-- SAML 1 and 2 encoders for the attribute. -->
<resolver:AttributeEncoder xsi:type="SAML1String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
name="urn:mace:dir:attribute-def:eduPersonAffiliation" />
<resolver:AttributeEncoder xsi:type="SAML2String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
name="urn:oid:1.3.6.1.4.1.5923.1.1.1.1"
friendlyName="eduPersonAffiliation" />
<resolver:AttributeEncoder xsi:type="SAML1String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
name="urn:mace:dir:attribute-def:eduPersonAffiliation" />
<resolver:AttributeEncoder xsi:type="SAML2String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
name="urn:oid:1.3.6.1.4.1.5923.1.1.1.1"
friendlyName="eduPersonAffiliation" />
<!-- The script, wrapped in a CDATA section so that special XML characters don't need to be removed -->
<Script><![CDATA[
importPackage(Packages.edu.internet2.middleware.shibboleth.common.attribute.provider);
<Script><![CDATA[
importPackage(Packages.edu.internet2.middleware.shibboleth.common.attribute.provider);
eduPersonAffiliation = new BasicAttribute("eduPersonAffiliation");
// If the user has group membership
if (typeof memberOf != "undefined" && memberOf != null ){
if (typeof memberOf != "undefined" && memberOf != null ){
for (i=0; memberOf != null && i < memberOf.getValues().size(); i++) {
value = memberOf.getValues().get(i).toLowerCase();
if (value.contains("teachers")) {
eduPersonAffiliation.getValues().add("staff");
eduPersonAffiliation.getValues().add("member");
}
eduPersonAffiliation.getValues().add("staff");
eduPersonAffiliation.getValues().add("member");
}
if (value.contains("students")) {
eduPersonAffiliation.getValues().add("student");
eduPersonAffiliation.getValues().add("member");
}
eduPersonAffiliation.getValues().add("student");
eduPersonAffiliation.getValues().add("member");
}
}
}
]]></Script>
</resolver:AttributeDefinition>
}
]]></Script>
</resolver:AttributeDefinition>
You then need to configure eduPersonScopedAffiliation to use eduPersonAffiliation as its source (uncomment it if need be)
<resolver:AttributeDefinition id="eduPersonScopedAffiliation"
xsi:type="Scoped" xmlns="urn:mace:shibboleth:2.0:resolver:ad"
scope="yourdomain.com" sourceAttributeID="eduPersonAffiliation">
xsi:type="Scoped" xmlns="urn:mace:shibboleth:2.0:resolver:ad"
scope="yourdomain.com" sourceAttributeID="eduPersonAffiliation">
<resolver:Dependency ref="eduPersonAffiliation" />
<resolver:AttributeEncoder xsi:type="SAML1ScopedString"
xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
name="urn:mace:dir:attribute-def:eduPersonScopedAffiliation" />
xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
name="urn:mace:dir:attribute-def:eduPersonScopedAffiliation" />
<resolver:AttributeEncoder xsi:type="SAML2ScopedString"
xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
name="urn:oid:1.3.6.1.4.1.5923.1.1.1.9"
friendlyName="eduPersonScopedAffiliation" />
xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
name="urn:oid:1.3.6.1.4.1.5923.1.1.1.9"
friendlyName="eduPersonScopedAffiliation" />
</resolver:AttributeDefinition>
We then used the UK Federation test SP’s session dumper to see what had been released.
Labels:
active directory,
idp,
opensource,
shibboleth
Saturday, 11 September 2010
Using servermanagercmd to automate the installation of common roles and features in Windows Server 2008 (inc R2)
I try to configure as many of the settings on a server via group policy. This not only saves time, but provides 100% consistency and a very simple way of making system wide changes. An example of this is I will configure SNMP settings via group policy.
This is all well and good, but many of the configuration settings are dependent on a “role” or “feature” that may not be installed (such as SNMP) there is no built in way to automatically install roles and features using group policy like there is to configure services, or firewall rules.
This is where servermanagercmd comes in. as you will probably gather this is a command line interface to the server manager GUI.
If you’re deploying a large amount of servers and you want to avoid manually installing a common role or feature, this is very useful, and will save hundreds of clicks!
Within the Active Directory design of the network I support, each server role has its own OU, which is under a generic servers OU. In most cases there is a group policy applied to each OU, so settings specific to a server role can be set.
Because of this, I can use group policy preferences to create a registry entry under the runonce key which will run servermanagercmd with the appropriate switches to install what I want based on the role of the server.
The runonce key is located:
HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce
Any REG_SZ string that is created under this key will be run once on startup (hense the name)
I typically install three features on most of the servers I look after, Telnet Client, SNMP Services and Failover clustering, these are the commands I use:
Servermanagercmd –install –telnet-client
Servermanagercmd –install snmp-services –allsubfeatures
Servermanagercmd –install failover-clustering
You will notice on the SNMP string, I have added –allsubfeatures, this installs all the sub features under the feature or role heading you have specified.
More information on the servermanagercmd as well as switches for other roles and features can be found here:
http://technet.microsoft.com/en-us/library/cc748918(WS.10).aspx
Other switches of servermanagercmd worth noting are:
-query this will output the current roles and features installed
-remove this does the opposite of add
This is all well and good, but many of the configuration settings are dependent on a “role” or “feature” that may not be installed (such as SNMP) there is no built in way to automatically install roles and features using group policy like there is to configure services, or firewall rules.
This is where servermanagercmd comes in. as you will probably gather this is a command line interface to the server manager GUI.
If you’re deploying a large amount of servers and you want to avoid manually installing a common role or feature, this is very useful, and will save hundreds of clicks!
Within the Active Directory design of the network I support, each server role has its own OU, which is under a generic servers OU. In most cases there is a group policy applied to each OU, so settings specific to a server role can be set.
Because of this, I can use group policy preferences to create a registry entry under the runonce key which will run servermanagercmd with the appropriate switches to install what I want based on the role of the server.
The runonce key is located:
HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce
I typically install three features on most of the servers I look after, Telnet Client, SNMP Services and Failover clustering, these are the commands I use:
Servermanagercmd –install –telnet-client
Servermanagercmd –install snmp-services –allsubfeatures
Servermanagercmd –install failover-clustering
More information on the servermanagercmd as well as switches for other roles and features can be found here:
http://technet.microsoft.com/en-us/library/cc748918(WS.10).aspx
Other switches of servermanagercmd worth noting are:
-query this will output the current roles and features installed
-remove this does the opposite of add
Labels:
automation,
command line,
server 2008,
server 2008 r2,
windows
Friday, 10 September 2010
Shibboleth IdP not writing logs to the logs directory
I’ve recently been tasked with implementing a Shibboleth IdP for the network I support. The service has been implemented on a Windows Server 2008 R2 server running Tomcat and fronted by Apache and Microsoft Forefront TMG 2010.
I will post more on the implementation of this later, but a quick bit of info to resolve an issue that had me pulling my hair out for most of a day.
Shibboleth has a logs directory within its installation directory, in my setup the shibboleth directory was c:\program files (x86)\shibboleth-idp
I found that the shibboleth logs directory wasn’t filling up with anything. I searched around for hours to discover the cause and eventually found the answer here:
https://spaces.internet2.edu/display/SHIB2/IdPLogging
Basically, the logging mechanism used by shibboleth IdP does not support a path with brackets in it, so on any x64 system by default this would fail.
To resolve that I changed the log paths in the logging.xml file in the shibboleth conf directory to point to c:\shiblogs
After bouncing the tomcat service, logs appeared.
I will post more on the implementation of this later, but a quick bit of info to resolve an issue that had me pulling my hair out for most of a day.
Shibboleth has a logs directory within its installation directory, in my setup the shibboleth directory was c:\program files (x86)\shibboleth-idp
I found that the shibboleth logs directory wasn’t filling up with anything. I searched around for hours to discover the cause and eventually found the answer here:
https://spaces.internet2.edu/display/SHIB2/IdPLogging
Basically, the logging mechanism used by shibboleth IdP does not support a path with brackets in it, so on any x64 system by default this would fail.
To resolve that I changed the log paths in the logging.xml file in the shibboleth conf directory to point to c:\shiblogs
After bouncing the tomcat service, logs appeared.
Labels:
idp,
opensource,
shibboleth,
windows
Thursday, 9 September 2010
Labelling those NIC’s
Tracing cables in a busy rack is a nightmare. Many people who share my switchport labelling OCD will always label up the port on the switch in a format such as “Link to MyServer01” and this is good. However it seems it’s not such common practise to label up where on the server the connection goes to, and then at the server end, where the connection goes to.
Most server’s today have PCI slots labelled in numerical form, and anyone with common sense will count the NIC’s from left to right. With the huge uptake of virtualisation, servers are now packed with NIC’s, Therefore my plea starts today, let’s start labelling server NIC ports in the same way we label switch ports.
The image below is a screenshot from one of the servers i look after. There are two quad port NIC’s installed in PCI slots one and two. Therefore I have adopted the naming convention “Slot X – NIC X – Link to Switchname giX-X” then on the switch side its reversed, the port is labelled as “link to MyServer01 NIC x\x . Implementing this method of labelling does take a bit of extra time and effort to keep up to date, but it will make yours and others life’s supporting the network so much easier. You can now tell exactly where a link goes from either the server or the switch end. I also add to the server NIC label what the NIC is used for eg “Slot X – NIC X – Link to switchname gix-x – Hyper-V Host Management” it’s a long label but your find it very useful!
Most server’s today have PCI slots labelled in numerical form, and anyone with common sense will count the NIC’s from left to right. With the huge uptake of virtualisation, servers are now packed with NIC’s, Therefore my plea starts today, let’s start labelling server NIC ports in the same way we label switch ports.
The image below is a screenshot from one of the servers i look after. There are two quad port NIC’s installed in PCI slots one and two. Therefore I have adopted the naming convention “Slot X – NIC X – Link to Switchname giX-X” then on the switch side its reversed, the port is labelled as “link to MyServer01 NIC x\x . Implementing this method of labelling does take a bit of extra time and effort to keep up to date, but it will make yours and others life’s supporting the network so much easier. You can now tell exactly where a link goes from either the server or the switch end. I also add to the server NIC label what the NIC is used for eg “Slot X – NIC X – Link to switchname gix-x – Hyper-V Host Management” it’s a long label but your find it very useful!
Labels:
networking,
tidy,
windows
Subscribe to:
Posts (Atom)
Blog Archive
-
▼
2010
(12)
-
▼
September
(8)
- Essential tools for today’s admins and where to do...
- Installing a System Centre Essentials 2010 agent m...
- SAN Certificates – a great way to get more for you...
- Configuring shibboleth IdP to talk to an Active Di...
- Shibboleth IdP – Getting the eduPersonScopedAffili...
- Using servermanagercmd to automate the installatio...
- Shibboleth IdP not writing logs to the logs directory
- Labelling those NIC’s
-
▼
September
(8)