top of page

OUR PRECONDITIONS

  • The old network infrastructure, referred to as OldNet:
    Doesn’t support 802.1x.
    Two domains on different VLAN’s with a one way trust, referred to as Enterprise and Educational.
    The two domains have their own network infrastructure, different IP Helpers, DNS, DHCP and so on.

  • The new infrastructure, referred to as NewNet:
    802.1x is required using CISCO ISE and Layer 3 switches.
    Only one fallback net with its own IP range, common for both domains, which also supports WebAuth guest access.
    The two domains still have their own IP range, DHCP, DNS etc. but will use the same PXE-server since PXE boot is taking place on the fallback network.

  • Both the old and the new network infrastructure will be used to deploy Windows 10 x64 and Windows 7 x86.

  • MAB will not be used during OSD, the network team don’t want to spread a special OSD VLAN so clients will get an IP address according to its current location and only certificate-based authentication is allowed.

  • The task sequence needs to support both the new computer and refresh scenario as well as BIOS to UEFI conversion regardless of the currently installed operating system.
    The scripts used for managing 802.1x needs to support Windows 7 and its PowerShell version.

Search
Writer's picturesomeguy100
Oct 18, 20182 min read

Here you'll find all the steps needed.

This is a great site which covers most parts of 802.1x during OSD. If you can't find what you're looking for in the link below, then maybe you'll find it here.

But I won't write the same things when it's already been done in such a good way

What I especially agree with is part 5 about whitelisting clients, if that's an option for you! http://www.asquaredozen.com/2018/07/29/configuring-802-1x-authentication-for-windows-deployment/

I've looked at using the RESTful API and whitelist clients during OSD... But not in the way described in the guide. That's one of the few things I disagree with in all the 5 parts. Why? If I understood it correct, the script is launched during OSD on the client side. And the password to add any computer/MAC to the whitelist group is there in plain text? No, no, not good at all if that's the case.


We have a webmanager for adding computers to the site and where we can choose what OSD the client should get. It was made for SCCM 2007 and its functions. The people who made it "had left the building" a long time ago but I managed to rewrite the parts needed in order for it to work with SCCM CB. This is where the whitelisting should happen if you ask me, on the server side. And the removal of client from the group should be done with a "status message rule" that triggers a script. Don't know if it's just me being picky, but it feels better that way :P


And btw, I recently discovered a great tool for launching server side commands during OSD, Onevinn SCCM Extensions, so if you don't have the luxury of a webmanager, use that! That is if you don't want to spend hours finding out how to send variables in a custom status message and triggering a script with them as arguments. Just don't, it's not worth it.



221 views0 comments

Comments

bottom of page