Configuring default FTP logon domain

If you’re still stuck in the dark insecure age of the internet and using FTP, you may want users to login to your FTP site using their domain credentials.

By default, the FTP service will use the local user database on the server itself (unless you enter your username in the domain\username format), you can however configure IIS to use a domain by default.

Take caution in doing this though, if you’ve ever put an FTP server on the internet, take a look at the event logs, it will have a ton of brute force attacks on it within minutes.
By default FTP will be trying to authenticate locally, which is a much smaller attack surface (fewer users) as soon as you point it at your domain, it’s going to have a much larger attack surface (more users)

You need to make sure you don’t have any accounts such as “test” or users like “mary” with passwords of “password” or any dictionary word at all. You should also tie the FTP site down to the specific users that need access, so if an account does get compromised it can’t be used to put data in the FTP directory.
With the above in mind, use an elevated command prompt to run the following on the FTP server

adsutil set msftpsvc/DefaultLogonDomain "YourDomainName"

This will set the default logon domain for all FTP sites.

Creating a dynamic distribution group based on any Active Directory attribute in exchange 2010

A Common requirement I’m sure for most businesses is to be able to send a mail to all users who are located in a specific building.

A dynamic distribution group based on the office attribute is surely the answer – well yes it is, but not using the Exchange Management Console.

I have the office attribute set for each user within active directory

However, if you use the exchange management console to build your query, its options are limited and does not include the office attribute.

Although using the EMC it isn’t possible, it can be done in powershell.

The new-dynamicdistributiongroup cmdlet doesn’t natively support anything other than the attributes you see listed in the EMC, however you can use a recipientfilter to specify any attribute you like.

The command below will create a dynamic distribution group called “Users in Example Office name” which will contain any user with the office location set to “Example office Name”

New-DynamicDistributionGroup -Name "Users in Example Office Name" -OrganizationalUnit "domain.net\users" -RecipientFilter { ((RecipientType -eq 'UserMailbox') –and (Office -eq 'Users in example office name')) }

This command can be extended futher using the –and variable. The command below would create the same dynamic distribution group, only the members would be those who are in the “Example office name” building AND their manager is James Bond

New-DynamicDistributionGroup -Name "Users in Example Office Name" -OrganizationalUnit "domain.net\users" -RecipientFilter { ((RecipientType -eq 'UserMailbox') -and (Manager –eq 'James Bond') –and (Office -eq 'Users in example office name')) }

A quick way to set calendar permissions using Powershell

A Common request from users is to grant others access to their calendars.
You can either talk the user through this, or setup a new outlook profile to open their mailbox and set it yourself using the GUI – both are time consuming.
This simple powershell command allows you to set permissions with ease:

add-mailboxfolderpermission -identity USERNAME:\calendar -user "Username of person who needs access" -accessrights reviewer

The Identity switch needs to be the username of the mailbox which you are giving access TO, the user switch is the user you are giving access FROM.
The accessrights switch is the level of access you wish to grant the user, the link below lists some additional switches you can use:

http://technet.microsoft.com/en-us/library/dd298062.aspx

Using a PAC file to set proxy settings

There are many ways to configure proxy settings, via a GPO, via a build, or an application.

Proxy settings can cause issues for mobile users if they use their device away from the corporate LAN as the proxy server will not be reachable, this will render the internet browser unusable (unless of course Direct Access has been implemented)

There are many solutions to this problem, some common ones are:
1. Teach users to enable and disable proxy settings, This is not the most elegant solution, is likely to cause a fair amount of support calls, and also means proxy settings cannot be enforced.
2. Run a 3rd party app that users can click on and select proxy on or proxy off. Im not a fan of these types of applications that sit there and use up resources for no real reason.

3. Run a login script that sets the proxy setting if you are connected to the corporate LAN, and doesn’t if you are not. This is a long winded way of doing it, and is not 100% effective.

In my opinion, the most effective and efficient way of configuring proxy settings is to use a proxy auto config file (PAC)
A PAC file contains a JavaScript function "FindProxyForURL(url, host)". This function returns a string with one or more access method specifications. These specifications cause the user agent to use a particular proxy server or to connect directly
.
You configure your browser (works in all popular browsers) to use a script to configure proxy settings, this setting remains in place permantly. If the PAC file is placed on a web server accessible only within the corporate LAN, if the user is away from the LAN, the config file is not found, so therefore a proxy is not used.

When the user is within the LAN, the file is found, and proxy settings configured.
Some say that a login script can achieve this too, however the login script requires you to login to take effect.

Take a scenario where a user is in the office, closes the lid on his or her laptop, gets on the train then opens the lid, and connects via 3G.
If proxy settings were configured with a login script, the office proxy settings would still be present unless the user logged off and on again.
With a PAC method in place, the browser looks for the settings each time a page is requested, therefore it would fail to find the config file and connect directly.
Below is an example PAC file which can be modified to suit your needs. This could be further extended to look at the current IP of the client, and return a different proxy depending on where the client is. Eg if the client is within an IP range which is associated with the Paris office, the Paris proxy would be returned, or if the client is on a New York IP range, the New York proxy would be returned.

function FindProxyForURL(url, host)
 {
        
        // Direct connections to Hosts
         if (isPlainHostName(host) ||
         (host == "127.0.0.1") ||
         (host == "www.a-whole-domain.com") ||
         (shExpMatch(host, "*.a-entire-domain.com")) ||
         (shExpMatch(host, "10.20.30.*"))) {
           return "DIRECT"
         } else {
           return "PROXY proxy-server.domain.com:8080"
         }
 }

Within this file, access to the IP range 10.20.30.0 - 10.20.30.255 would be accessed directly (bypassing the proxy) aswell as the domain www.a-whole-domain.com. anything under the domain a-entire.domain.com would also bypass the proxy. everything else will be directed at the proxy server "proxy-server.domain.com" on port 8080.
Add additional sites to the proxy bypass list by copying an existing line and pasting it below.


Although a WPAD file could also offer similar functionality, in my experience a PAC file is much more flexible and will enable changes to take effect instantly.

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

// 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";

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

https://spaces.internet2.edu/display/SHIB2/ResolverScriptAttributeDefinitionExamples#ResolverScriptAttributeDefinitionExamples-ex2

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!

http://wiki.rscwmsystems.org.uk/images/1/11/Shibboleth2_IdP_Setup_Win2k.pdf

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

    <!-- Dependency that provides the source attribute. -->
    <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" />

    <!-- 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);

        eduPersonAffiliation = new BasicAttribute("eduPersonAffiliation");

        // If the user has group membership
        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");
                }

                if (value.contains("students")) {
                    eduPersonAffiliation.getValues().add("student");
                    eduPersonAffiliation.getValues().add("member");
                }

            }
        }
    ]]></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">

    <resolver:Dependency ref="eduPersonAffiliation" />

    <resolver:AttributeEncoder xsi:type="SAML1ScopedString"
      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" />

</resolver:AttributeDefinition>

We then used the UK Federation test SP’s session dumper to see what had been released.

https://sh2testsp1.iay.org.uk/index.html