Home

Server 2019 Network Profile, Network Location Awareness and RADIUS issues

%3CLINGO-SUB%20id%3D%22lingo-sub-322432%22%20slang%3D%22en-US%22%3EServer%202019%20Network%20Profile%2C%20Network%20Location%20Awareness%20and%20RADIUS%20issues%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-322432%22%20slang%3D%22en-US%22%3E%3CP%3EI'm%20presently%20checking%20out%20Serve%202019%20in%20the%20lab.%20Did%20a%20clean%20install%20of%20Server%202019%20and%20installation%20went%20flawless.%20Set%20up%20as%20PDC%20and%20for%20now%20this%20is%20the%20only%20DC%20on%20the%20network%20and%20as%20of%20yet%20no%20workstations%20are%20joined%20to%20the%20domain.%20I%20did%20however%20test%20to%20confirm%20I%20can%20join%20workstations%2C%20and%20can%20do%20so%20with%20no%20issues.%20The%20issues%20start%20when%20attempting%20to%20connect%20a%20wireless%20computer%20to%20the%20network.%3C%2FP%3E%3CP%3EFirst%20issue%20is%20that%20after%20installation%20and%20promotion%20to%20DC%2C%20Network%20%26amp%3B%20Sharing%20Center%20shows%20the%20server%20as%20being%20%22Public%22.%20Via%20Powershell%20I%20can%20switch%20it%20to%20Private%2C%20but%20can%20not%20switch%20to%20Domain.%20The%20message%20states%20it%20must%20first%20be%20%22authenticated%22.%20Huh%3F%20I%20since%20discovered%20that%20if%20I%20stop%2Frestart%20NLA%2C%20then%20it%20immediately%20shows%20the%20network%20profile%20as%20Domain%2C%20and%20Windows%20Defender%20Firewall%20in%20control%20panel%20correctly%20shows%20that%20as%20the%20%22active%22%20profile.%26nbsp%3B%20So%20I%20changed%20the%20NLA%20service%20from%20Automatic%2C%20to%20Automatic%20(Delayed%20Start)%20and%20rebooted%20the%20server.%20No%20change.%20Even%20with%20a%20delayed%20start%20it%20still%20defaulted%20to%20the%20Private%20network%20profile.%20But%20a%20quick%20stop%2Frestart%20of%20NLA%20instantly%20changed%20it%20to%20the%20Domain%20network%20profile.%3C%2FP%3E%3CP%3E%26nbsp%3B%26nbsp%3B%20Next%2C%20I%20have%20a%20wireless%20access%20point%20set%20up%20to%20use%20this%20Server%202019%20setup%20as%20the%20RADIUS%20server.%20I%20was%20able%20to%20correctly%20configure%20RADIUS%20for%20the%20WAP%20in%20NPS%20using%20the%20wizard%20to%20do%20so.%20A%20check%20of%20the%20RADIUS%20clients%20as%20well%20as%20the%20secure%20wireless%20connection%20policies%20shows%20they%20are%20all%20correctly%20configured%20on%20the%20server.%3C%2FP%3E%3CP%3ENow%20when%20I%20try%20to%20connect%20to%20the%20WAP%20from%20my%20wireless%20laptop%20I%20am%20correctly%20prompted%20for%20my%20domain%20login%20credentials%20(presently%20using%20the%20domain%20administrator%20credentials)%20but%20it%20fails%20with%20an%20%22unable%20to%20connect%22%20error.%3C%2FP%3E%3CP%3EI've%20checked%20that%20UDP%20ports%201812%20and%201813%20are%20open%20on%20the%20domain%20profile%2C%20and%20they%20are%20open.%20However%2C%20I%20still%20can't%20connect.%20However%2C%20if%20I%20turn%20off%20the%20firewall%20for%20the%20domain%20only%2C%20then%20it%20connects%20with%20no%20issue.%20So%20I%20suspect%20this%20has%20something%20to%20do%20with%20AD%20DS%20access%20through%20the%20firewall.%20But%20I've%20not%20a%20clue%20what%20ports%20to%20check.%3C%2FP%3E%3CP%3ESo%20in%20conclusion%2C%20I've%20identified%20two%20issues%20thus%20far%20with%20server%202019.%3C%2FP%3E%3CP%3E%26nbsp%3B-%20NLA%20for%20some%20reason%20must%20be%20restarted%20manually%20to%20get%20the%20correct%20%22Domain%22%20network%20profile.%3C%2FP%3E%3CP%3E%26nbsp%3B-%20Wireless%20access%20via%20RADIUS%20will%20not%20work%20unless%20the%20domain%20firewall%20is%20turned%20off.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-322432%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EWindows%20Server%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-553435%22%20slang%3D%22en-US%22%3ERe%3A%20Server%202019%20Network%20Profile%2C%20Network%20Location%20Awareness%20and%20RADIUS%20issues%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-553435%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F269640%22%20target%3D%22_blank%22%3E%40Carl1959%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWe%20are%20seeing%20this%20across%20all%202019%20Domain%20Controllers%20we%20support%20out%20in%20the%20field.%26nbsp%3B%20Restarting%20the%20Network%20Location%20Awareness%20service%20will%20%22fix%22%20RADIUS%20communication%20for%20a%20time%2C%20but%20inevitably%20the%20issue%20returns.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20had%20thought%20hat%20setting%20NLA%20to%20Automatic%20(Delayed%20Start)%20would%20solve%20the%20problem%2C%20thinking%20it%20was%20related%20to%20DNS%20Server%20taking%20a%20longer-than-expected%20time%20to%20start%2C%20but%20this%20does%20not%20appear%20to%20be%20the%20case.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-787275%22%20slang%3D%22en-US%22%3ERe%3A%20Server%202019%20Network%20Profile%2C%20Network%20Location%20Awareness%20and%20RADIUS%20issues%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-787275%22%20slang%3D%22en-US%22%3E%3CP%3EI%20have%20the%20exact%20same%20problem%20on%20a%20fully%20updated%20server%20in%20August.%3C%2FP%3E%3CP%3EThe%20default%20rules%20for%20Network%20Policy%20Server%20does%20not%20work.%20Even%20if%20they%20show%20port%201812%20as%20allowed%20they%20do%20not%20work.%3C%2FP%3E%3CP%3EIf%20I%20delete%20this%20rule%20and%20create%20a%20manual%20rule%20allowing%20port%201812%20for%20any%20program%20radius%20communication%20works%20as%20expected.%3C%2FP%3E%3C%2FLINGO-BODY%3E
Carl1959
Occasional Visitor

I'm presently checking out Serve 2019 in the lab. Did a clean install of Server 2019 and installation went flawless. Set up as PDC and for now this is the only DC on the network and as of yet no workstations are joined to the domain. I did however test to confirm I can join workstations, and can do so with no issues. The issues start when attempting to connect a wireless computer to the network.

First issue is that after installation and promotion to DC, Network & Sharing Center shows the server as being "Public". Via Powershell I can switch it to Private, but can not switch to Domain. The message states it must first be "authenticated". Huh? I since discovered that if I stop/restart NLA, then it immediately shows the network profile as Domain, and Windows Defender Firewall in control panel correctly shows that as the "active" profile.  So I changed the NLA service from Automatic, to Automatic (Delayed Start) and rebooted the server. No change. Even with a delayed start it still defaulted to the Private network profile. But a quick stop/restart of NLA instantly changed it to the Domain network profile.

   Next, I have a wireless access point set up to use this Server 2019 setup as the RADIUS server. I was able to correctly configure RADIUS for the WAP in NPS using the wizard to do so. A check of the RADIUS clients as well as the secure wireless connection policies shows they are all correctly configured on the server.

Now when I try to connect to the WAP from my wireless laptop I am correctly prompted for my domain login credentials (presently using the domain administrator credentials) but it fails with an "unable to connect" error.

I've checked that UDP ports 1812 and 1813 are open on the domain profile, and they are open. However, I still can't connect. However, if I turn off the firewall for the domain only, then it connects with no issue. So I suspect this has something to do with AD DS access through the firewall. But I've not a clue what ports to check.

So in conclusion, I've identified two issues thus far with server 2019.

 - NLA for some reason must be restarted manually to get the correct "Domain" network profile.

 - Wireless access via RADIUS will not work unless the domain firewall is turned off.

 

2 Replies

@Carl1959 

 

We are seeing this across all 2019 Domain Controllers we support out in the field.  Restarting the Network Location Awareness service will "fix" RADIUS communication for a time, but inevitably the issue returns.

 

I had thought hat setting NLA to Automatic (Delayed Start) would solve the problem, thinking it was related to DNS Server taking a longer-than-expected time to start, but this does not appear to be the case.

I have the exact same problem on a fully updated server in August.

The default rules for Network Policy Server does not work. Even if they show port 1812 as allowed they do not work.

If I delete this rule and create a manual rule allowing port 1812 for any program radius communication works as expected.

Related Conversations
Tabs and Dark Mode
cjc2112 in Discussions on
35 Replies
Extentions Synchronization
Deleted in Discussions on
3 Replies
flashing a white screen while open new tab
Deleted in Discussions on
14 Replies
How to Prevent Teams from Auto-Launch
chenrylee in Microsoft Teams on
29 Replies
Security Community Webinars
Valon_Kolica in Security, Privacy & Compliance on
9 Replies