Your basic ITPro blog... What's going on at work, what I'm interested in.

Tuesday, December 21, 2010

Authentication For Cisco ASA5510 VPN Clients

We have two connectivity methods that require user authentication, VPN and wireless. Specifically, regarding wireless, we have two main SSIDs, one for guests and one for network users. Guest Access only allows users connected to get to the Internet. Access lists on our routers prevent devices on the Guest VLAN from accessing our network resources. Anyone can connect to this SSID.

Network LAN access is made available by a second SSID. Our Cisco Wireless LAN Controller allows only authenticated users onto this WLAN. Currently, it is configured to use one of our old DCs as a RADIUS server for this purpose. User who connect have two requirements; 1)valid AD account, and 2)membership in a specific AD group. I am hoping to migrate this to our new domain very soon.

Our Cisco ASA5510 was also configured to use our old DC as a RADIUS server to authenticate VPN clients. Like wireless, users had to have a valid AD account and be a member of a ‘Valid VPN Users’ AD group to be granted access. Yesterday, we did some work to move VPN authentication to our new AD Domain. The biggest win, I think, was switching from RADIUS to LDAP as the mechanism for this. With LDAP, there is no need to make any changes, or install anything additional, on our DCs. This is big, as it helps keep my DCs clean and uncomplicated, minimizing the roles required to run on these machines.

I am going to try and share some screencaps of the config… we will see how much I need to ‘blur out’. Hopefully, they will still be helpful and informative.

The big change we made was in the AAA Server Groups area on the ASA5510.

- We created a new AAA Server Group, just calling it ‘LDAP’.

- Under ‘Servers’, I added one of our DCs. The config is as follows:

image

  • Server Name or IP Address – Just the IP of my DC
  • Base DN – The DN of the container for my user accounts
    • The ‘Scope’ setting allows for more than one level beneath the Base DN, so if you need to search a larger section of AD, you easily can.
  • Login DN and Login Password: Credentials for a domain account used for AD lookups. This account doesn’t need access to anything, just needs to be able to authenticate in AD.
  • Group Base DN: This is the DN to the location of the group that users much be a member of to gain access.

With this set up, I then needed to modify the Connection Profile used for VPN, as well as the Group Policy. Group Policy first:

  • I copied the existing Group Policy into a new one and changed the required settings.
    • The only change I made was on the “Servers” menu item, changing the DNS Servers, WINS Servers, and Default Domain to all point to our new AD domain.

After the new Group Policy was created, I updated my Connection Profiles as needed:

  • On the ‘Basic’ menu, I changed the AAA Server Group to my new LDAP server group.
  • I changed the Group Policy to my new group policy.

The last step was getting the ‘group membership’ requirement activated. This is done under ‘Dynamic Access Policies’ (DAP). We originally only had one DAP, the default, named DfltAccessPolicy. This is a catch-all policy that is applied if no other policy matches the authenticating user.

  • I created a new DAP:
    • Selection Criteria
      • AAA Attribute Type: LDAP
      • Attribute ID: memberOf
      • Value:  = <name of AD group user must be a member of>
        • There is a “Get AD Groups” button that should access your AD and pull a list of groups, if your AAA Server settings are correct.
    • Under ‘Access/Authorization Policy Attributes’
      • Action:  Continue
  • Changed the action on the ‘DfltAccessPolicy’ to “Terminate”

VOILA! Users authenticating, via LDAP, against my AD with group membership requirements. Obviously, things can get much more complicated and granular. But, for us, this is working perfectly.

* Got to give another shout-out to BriComp Computers for their help with this. He helped me with everything but the ‘group membership’ part of this. Gave me a huge head-start!

Now, on to figuring out the WLC…

Active Directory Migration–2003 to 2008 R2

It is exciting to be able to say that our Active Directory migration is complete. Sure, there are some straggling issues, but the main migration is finished. Over all, this project was very successful.

A quick recap of what we did…

I posted a brief update on things earlier. We have since migrated all of the resources in our old domain to the new Windows 2008 R2 domain… all resources EXCEPT our Exchange 2003 environment and our SharePoint Services 3.0 environment. From what I understand, neither of those products are very friendly to AD Migration.

 Windows Server 2008 R2  >  Windows Server 2003

Leaving these resources in our old domain create some interesting usage issues for our users. Regarding SharePoint, I am looking to put a new SharePoint Foundation 2010 setup in our new domain and migrate resources to that. My hope is to just duplicate functionality and deprecate our old SS3.0 service without too much trouble. We don’t use SharePoint for too much, so this isn’t a huge deal. E-mail, on the other hand…

As you can probably imagine, we are eager to migrate our mail system to Exchange 2010. I am hoping this will happen in Q1 2011. We will see. In the meantime, email seems to work best when our users authenticate against Exchange (in Outlook or OWA) with their old domain credentials. So, users are logging in to their computers, accessing file shares, etc. using their new domain account, but have to remember to use their old domain account for email. Getting users to remember to juggle domains like this is “interesting”. I mean, I sometimes forget which resources needs which domain credentials. Then there’s the issue of creating new mail-enabled accounts. Interesting stuff.

I can say that the Active Directory Migration Tool is pretty awesome! It has worked very well for us and made migration a relative breeze!

I do want to give another hat tip to Brian Ricks at BriComp Computers, LLC. He has been a great resources and has been fun to work with as well.

Wednesday, November 10, 2010

P2V’d My Laptop

So, I am finally moving from XP to Win7 on my work machine. I had wanted to wait until getting a new laptop, as my current machine is almost 4 years old and only 32bit. But, the time has come to bite the bullet.

Now, the thought of just wiping my laptop and re-installing makes me ill. I mean, I have a lot installed and everything has a custom configuration. What I really want is to be able to run two machines, side by side, during my transition. That way, I can check settings, etc.

Hyper-V and VMM to the rescue!

I started a P2V operation in VMM last night before heading home. When I got in this morning, the job was complete.

Everything looks great and the VM is working perfectly. The only hiccup was that Windows had to be re-activated. Other than that, everything is working as expected.

Now it’s time to wipe the HD on that laptop and start the Win7 install.

Fun stuff!

Monday, November 8, 2010

Big Project: AD Upgrade via Migration and Domain Rename

So, we are in the middle of our first REALLY BIG project in a while. We are moving from our current Windows 2003 domain to a new Windows 2008 R2 domain. Included in this move is a domain rename. Whew!

We got two new servers to be our Win2008 DCs. They are all configured with the new domain and we are now running test migrations using ADMT 3.2.

We are using BriComp Computers, LLC as a consultant on this project that they have been great! Brian Ricks knows his stuff, has been helpful, available, and flexible with us. I am very excited to have him as part of our team for this (and likely future) projects.

I know the actual migration of our AD resources is going to be a big part of this, probably with hiccups along the way. But, I am excited about this and confident that we will squash any bugs that come along.

Thursday, November 4, 2010

E-mail Recipient Policy Changes In Bulk With Powershell

We are changing our Internet domain that we are using for email, web, etc. Part of this is setting up our exchange accounts to process the new SMTP addresses.

I’m not going to go into the detail of how to roll out new SMTP addresses to all of your accounts.What I wanted to share was a Powershell one-liner that I ended up using to find accounts that were not configured to accept automatic updates to their SMTP addresses.

In ADUC, open up Properties on an account and check the ‘E-mail Addresses’ tab. At the bottom is a check-box labeled “Automatically update e-mail addresses based on recipient policy”. If this checkbox is UNchecked, then policy updates are blocked.

For some reason, some of our accounts had this unchecked (most were checked). So, I wanted a way to find these AD objects and CHECK that box, without having to actually open properties on every object in AD.

Enter Powershell (with the Quest AD Cmdlets, of course)!

The magic one-liner is: 

get-qaduser -IncludedProperties msExchPoliciesExcluded | where {$_.msExchPoliciesExcluded -ne $null} | foreach-object {set-qaduser $_ -ObjectAttributes @{msExchPoliciesExcluded=''} -whatif}

The ‘-whatif’ at the end just tells the command to do a test run. Remove the –whatif to actually make the change (check the checkbox).

I ran the one-liner a second time (minus the ‘foreach-object’ block), changing ‘get-qaduser’ at the beginning to ‘get-qadgroup’ to see if I had any mail-enabled groups that needed to be updated also. I didn’t. If you do, just change ‘qaduser’ to ‘qadgroup’ as needed.

Thanks To:

http://social.technet.microsoft.com/Forums/en-US/ITCG/thread/1dacb47d-e513-478f-be97-4cb791e467dd

Thursday, September 9, 2010

Network-In-A-Box Solution For Our New Campus

So, we are opening a third campus this week. Exciting! This new campus provided challenges for us that created great opportunities to grow and use new technology. We need to be able to provide Check-In services to our children’s ministries at this new location. So, we need to deploy check-in kiosks that communicate with our servers back on our Mesa campus. There are some key realities this launch presented that created the need for a unique (to us) solution.

  1. Church-In-A-Box: We will be renting a space for this campus, so our ‘church’ will need to be set up and torn down each week. We don’t have the ability to build in a permanent infrastructure like we have on our two current campuses. So, we need to have a solution that is flexible and mobile.
  2. Repeatable: As we look to the years ahead, expansion and additional campuses will more likely include rented space. This model will likely be more feasible than buying land and putting up buildings. So, we need a solution that is repeatable and portable.
  3. Ease Of Use: Our solution needs to be plug-and-play. We will be using servant ministers to set up and tear down each week. Now, I love servant ministers! They serve out of a wonderful heart for God and His mission! But, the reality is that gear just tends to get beat up, especially gear that needs to be moved around, packed and unpacked, etc. Also, servant ministers aren’t always the most technically-proficient people. So we need something that was going to be rugged and super-easy to set up and get working.
  4. Self-Contained: We also wanted a solution that would not rely on the any provided technical infrastructure. This would give us much more freedom as we looked for venues. We didn’t want to have to rely on a provided network or computing infrastructure. We needed a network-in-a-box. All we need from the facility is power.

pic002 We explored the option of WiFi or 3G and VPN clients on our kiosks with printers directly attached. After some testing, it turned out that printing would not be responsive enough in this configuration. Printer performance is MUCH better if they are networked, rather than attached to the kiosks. But, printers can’t run VPN clients. We experimented with multiple NICs in the computers and network connection sharing to the printers. This did not work as we thought it might.

So, we realized that the best solution will require a router that can establish a VPN tunnel and then provide network service to our kiosks and printers. We toyed with the idea of using a computer with multiple NICs for this, using the local network as our Internet connection, and other ideas. But, after discussing this among ourselves, and running the project with our integrator/consultant (Sentinel Technologies), we came up with a set of requirements that we felt were optimal.

We wanted an all-in-one unit that would:

  • Provide 3G access for Internet connectivity, allowing us to not rely on local networking infrastructure.
  • Have Ethernet ports on the ‘inside’ that we could connect our gear to.
  • Support VPN tunneling over the 3G network to provide secure communication back to the Mothership.
  • Allow for communication initiated from either side of the VPN tunnel (two-way tunneling). This proves to be interesting, given the fact that one side of the connection is not ‘fixed’. Using 3G, our IP address will change from use to use. So, configuring fixed VPN tunnels is not possible. (HINT: dynamic route injection FTW!)
  • Optionally, we would like to have VLAN support and WiFi support for wireless clients on-site.

Enter the Cisco 800 Series!

881G-lgDue to time constraints and shipping delays from Cisco, we ended up purchasing a used router, Model 881G. It has everything we need and want, except for the WiFi built-in. It supports 3G and has four Ethernet ports. We are using a card from Sprint for 3G access. If we need to expand services on the back-end, we can add a switch for additional Ethernet connections, and a WiFi router for wireless connectivity. But, this model should serve our needs for this current installation just fine.

Once the unit arrived, we worked with an engineer from Sentinel to get the unit up and running. By the end of the day, we had our gear ready for testing. After a few fits and starts to work out some bugs, we connected the printers and kiosks to the router and powered everything on. After a minute or so, the router had established Internet access through the Sprint 3G card, had created the VPN tunnel back to our Mesa campus, and our ASA5510 in Mesa had dynamically established the required routing rules for two-way communication back through the VPN tunnel.

Our kiosks brought up the check-in site and we ran some tests. The check-in app was responsive and printing was surprisingly quick. It was smiles all the way around!

So, our final installation will look something like this:

pic003

Simple, compact, repeatable, mobile, responsive. Everything we were looking for in a solution.

Of course, the REAL test will be this Sunday morning. Wish us luck!

 

ON A SIDE NOTE: I want to say a HUGE ‘Great job and Thank You’ to the other guys on our team! David did an awesome job getting the Sprint card activated on short notice and prepping the kiosks and printers. Nick and Jason, from my limited understanding, did some MAJOR work on the check-in system to support this unique configuration. These guys are amazing devs and a pleasure to work with. Phil did a great job running the project, working with our integrator and finding alternatives when our “Plan A’s” didn’t quite work out. For a while, we weren’t sure if we were going to get a router on site in time! Great job to all!

Monday, May 10, 2010

Upgrading to Exchange 2010

Well, it looks like this task is finally upon us. We are currently planning to upgrade our Exchange 2003 environment to Exchange 2010. I have heard mixed reviews on the upgrade process. Most have said it is not too bad. Others have had… umm…. difficulties.

I have been reading everything I can on the subject and, at this point, feel fairly confident that I can get us migrated to a new system. My primary concern is the design of the new environment. Our current Exchange setup, while functional, isn’t exactly ‘best practice’. We don’t have the resources to truly do things ‘best practice’ (full redundancy, role/box ratio, etc.) but I am hoping to make some improvements to our implementation.

If anyone out there has any suggestions, resources, or tips… I would love to hear them!

Tuesday, February 16, 2010

Third Time’s a Charm

Quick Tip: If the install procedure for your software requires the shutting down of services on the server, it’s a good idea to turn off any monitoring systems that may auto-restart services it sees shutdown.

So, I was installing Backup Exec 2010 on my backup server, upgrading my in-place Backup Exec 12.5 installation. The first time I ran the install, it failed. Looking at the log, it said that it failed while shutting down the Backup Exec services. I checked and the services were running. So, I shut them down myself and re-ran the install. It failed again, with the same error. I looked again and the services were again running. Slightly confused, I stopped the services again. Then, just to double-check, I refreshed the Services screen. To my momentary amazement, the services were running again!

It didn’t take but a second to realize that the “problem” was What’s Up Gold (WUG). I have WUG monitoring my backup server and it is set to restart the Backup Exec services if they go down. So, I would switch the lights off and WUG, at the other end of the hall, would switch the lights back on! OFF-ON-BACKUP FAIL… repeat!

Putting my backup server into maintenance mode in WUG solved my problem.

Good to see that WUG is doing its job. Now, I just have to remember what jobs I have given it to do.

Two Projects…

One for sure and one a ‘probably’.

First, I will be upgrading our Backup Exec 12.5 system to Backup Exec 2010. I am excited about this, especially the new pass-through granular backup feature for Hyper-V and virtualized workloads. As I understand it, you can do granular restores from virtualized workloads (Exchange, SQL Server, etc.) without having to do  a discreet backup of the VM itself. You just have to do a backup on the VM host of the environment. Of course, you still need the Backup Exec agents everywhere – a Hyper-V agent on the VM Host server as well as Exchange and SQL Server agents on the VMs running those respective workloads. Then, once the agents are in place, you just need to run a backup on the VM host machine, grabbing all of the VMs in the process. Form there, you can then do granular restores (individual mail items, SQL DBs, etc.) I am reading more about it and am excited to try it out.

The second project is a third VM Host server for our environment. We currently have two Dell 2950s running Win2008/Hyper-V. We are looking to add an R710 to the mix. We don’t have everything worked out, but I am hoping that we will be able to explore Hyper-V R2, clustering, CSVs, Live Migration, etc. We will see.

Fun stuff!

Additional Info

My photo
email: support (AT) mangrumtech (DOT) com
mobile: 480-270-4332