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 17, 20182 min read

802.1x apart from the basics

Updated: Oct 18, 2018

I won't go through every step I took (in detail) since what I did is unique to how our environment is set up and nowdays there is a lot more information on the web about what you need. But here are two things, apart from the basics, which helped us. If anything is unclear or if you still have questions about this or the basics, feel free to ask =)


1. Logging and monitoring the progress.

Use Start-Transcript if you're using powershell, just make sure that you've got a stop-transcript where needed if the script fails and you got another Start-transcript targeting the same log file and no reboot is configured in between.

Some kind of visual progress is also a nice thing to have.


2. The configuration and making it as dynamic as possible. Don't hard code stuff. In 2 years, it might not be you who is goning to make a change. I'm mostly self taught so there might be better ways but I did a conf file and got the script to create PS variables of it.



Debugmode: Activates certain options in the script even though "Enable command support" is turned off.

SearchIP- start and -end: The expected IP range for the client (Since we got 3 different VLAN'S)


Cert: The name of the certificate that should be in the certificate store if everything worked as it should.


Verify- Server and Port: In certain conditions, the client might have the correct IP, the correct certificate, netsh says "Authenticated" but the client still can't reach what it is supposed to, it can't reach anything in fact due to the dot3svc service is beeing frozen. This was more usual a few ADK's ago but can still happen if you try to import multiple ethernet profiles or certificates.


But it has more uses. The certificate that is being imported right after the PXE boot, always puts the client on a VLAN where it will get an Enterprise IP. With this certificate the client is only allowed to communicate with the SCCM servers.

This is because we're booting it on the guest network. TFTP isn't a secure protocol and even though the client needs to be in the SCCM-site in order to get the PXE boot a mac address can easily be spoofed.

In other words, the client will get another certificate later on in the task sequence and if it's supposed to join the enterprise domain the client will still be in the same expected IP range as before.

But in order to verify that the new certificate was imported successfully amongs with everything else you need to test if the client can reach what it is supposed to, in this case the domain controller.



206 views0 comments

Comments

bottom of page