Windows 10 - VPN-Tunnel computerseitig einrichten
Tag zusammen
Ich bin dabei, in unserer Firma OpenVPN abzulösen durch das "neue" AlwaysOn-VPN von Microsoft (Nachfolger von Direct Access). RRAS- und NPS-Server laufen, das Ganze funktioniert. Wo es im Moment noch hapert ist auf der Clientseite. Folgendes Problem:
Ich habe dieses PowerShell-Script, welches mir den VPN-Tunnel auf dem Rechner ordnungsgemäss erstellt:
Wenn ich nun auf einem Notebook mit einem Benutzer einlogge, der lokale Adminrechte auf diesem Notebook hat, läuft das Script durch, der WAN Miniport Adapter in der Netzwerkumgebung wird erstellt und der Tunnel funktioniert nach einem Neustart einwandfrei.
Nun wird dieser WAN Miniport-Adapter aber nicht computerseitig erstellt. D.h. wenn sich nun ein anderer Benutzer einloggt, steht ihm dieser WAN Miniport Adapter und damit der Always On Tunnel nicht zur Verfügung. Der Tunnel ist also nur userseitig für den Benutzer verfügbar, mit dem der Tunnel erstellt wurde.
Nun bin ich hingegangen und hab mir gedacht: Kein Problem, lieber TuXHunT3R, dann machst du ein Loginscript mittels GPO, welches den Tunnel einfach erstellt. Das funktioniert auch, aber nur, wenn der Benutzer auf dem Notebook Adminrechte hat. Wenn nun ein "normaler" Benutzer dieses Script ausführt, wird der Tunnel nicht erstellt, da man zum Erstellen dieses Tunnel lokale Adminrechte braucht. Danke Microsoft, das ist ja wirklich wieder mal super gelöst.... Soviel zum Thema integrierte Lösung....
Nun habe ich verständlicherweise natürlich keine Lust, bei 150 Notebooks dem jeweiligen Benutzer Adminrechte zu geben, das Script händisch auszuführen und dem Benutzer die Adminrechte dann wieder wegzunehmen.
Hat jemand von euch eine Idee, wie man dies schlauer machen könnte? Sodass der Tunnel pro Rechner einmal erstellt wird und dann für jeden Benutzer zur Verfügung steht?
Besten Dank.
Wir setzen Windows 10 1909 Enterprise x64 ein, Update auf das Herbstupdate dieses Jahres ist geplant, sobald sich herausstellt, dass es stabil läuft. AOVPN läuft auf Windows Server 2019.
Ich bin dabei, in unserer Firma OpenVPN abzulösen durch das "neue" AlwaysOn-VPN von Microsoft (Nachfolger von Direct Access). RRAS- und NPS-Server laufen, das Ganze funktioniert. Wo es im Moment noch hapert ist auf der Clientseite. Folgendes Problem:
Ich habe dieses PowerShell-Script, welches mir den VPN-Tunnel auf dem Rechner ordnungsgemäss erstellt:
$ProfileName = 'AlwaysOn VPN'
$ProfileNameEscaped = $ProfileName -replace ' ', '%20'
$ProfileXML = '
<VPNProfile>
<DnsSuffix>ks-ag.local</DnsSuffix>
<NativeProfile>
<Servers>OEFENTLICHERDNSEINTRAG</Servers>
<NativeProtocolType>IKEv2</NativeProtocolType>
<Authentication>
<UserMethod>Eap</UserMethod>
<Eap>
<Configuration>
<EapHostConfig xmlns="http://www.microsoft.com/provisioning/EapHostConfig"><EapMethod><Type xmlns="http://www.microsoft.com/provisioning/EapCommon">25</Type><VendorId xmlns="http://www.microsoft.com/provisioning/EapCommon">0</VendorId><VendorType xmlns="http://www.microsoft.com/provisioning/EapCommon">0</VendorType><AuthorId xmlns="http://www.microsoft.com/provisioning/EapCommon">0</AuthorId></EapMethod><Config xmlns="http://www.microsoft.com/provisioning/EapHostConfig"><Eap xmlns="http://www.microsoft.com/provisioning/BaseEapConnectionPropertiesV1"><Type>25</Type><EapType xmlns="http://www.microsoft.com/provisioning/MsPeapConnectionPropertiesV1"><ServerValidation><DisableUserPromptForServerValidation>true</DisableUserPromptForServerValidation><ServerNames>ksaaop02.ks-ag.local</ServerNames><TrustedRootCA>6b 3e 46 2a b0 b0 f9 26 d9 07 47 58 95 0a 5b 52 8d 81 c9 2d </TrustedRootCA></ServerValidation><FastReconnect>true</FastReconnect><InnerEapOptional>false</InnerEapOptional><Eap xmlns="http://www.microsoft.com/provisioning/BaseEapConnectionPropertiesV1"><Type>13</Type><EapType xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV1"><CredentialsSource><CertificateStore><SimpleCertSelection>true</SimpleCertSelection></CertificateStore></CredentialsSource><ServerValidation><DisableUserPromptForServerValidation>true</DisableUserPromptForServerValidation><ServerNames>ksaaop02.ks-ag.local</ServerNames><TrustedRootCA>6b 3e 46 2a b0 b0 f9 26 d9 07 47 58 95 0a 5b 52 8d 81 c9 2d </TrustedRootCA><TrustedRootCA>6b 3e 46 2a b0 b0 f9 26 d9 07 47 58 95 0a 5b 52 8d 81 c9 2d </TrustedRootCA></ServerValidation><DifferentUsername>false</DifferentUsername><PerformServerValidation xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV2">true</PerformServerValidation><AcceptServerName xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV2">true</AcceptServerName><TLSExtensions xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV2"><FilteringInfo xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV3"><CAHashList Enabled="true"><IssuerHash>6b 3e 46 2a b0 b0 f9 26 d9 07 47 58 95 0a 5b 52 8d 81 c9 2d </IssuerHash></CAHashList></FilteringInfo></TLSExtensions></EapType></Eap><EnableQuarantineChecks>false</EnableQuarantineChecks><RequireCryptoBinding>false</RequireCryptoBinding><PeapExtensions><PerformServerValidation xmlns="http://www.microsoft.com/provisioning/MsPeapConnectionPropertiesV2">true</PerformServerValidation><AcceptServerName xmlns="http://www.microsoft.com/provisioning/MsPeapConnectionPropertiesV2">true</AcceptServerName></PeapExtensions></EapType></Eap></Config></EapHostConfig>
</Configuration>
</Eap>
</Authentication>
<RoutingPolicyType>ForceTunnel</RoutingPolicyType>
</NativeProfile>
<AlwaysOn>true</AlwaysOn>
<RememberCredentials>true</RememberCredentials>
<TrustedNetworkDetection>ks-ag.local</TrustedNetworkDetection>
<DomainNameInformation>
<DomainName>INTERNERDOMAINNAME</DomainName>
<DnsServers>172.16.1.50,172.16.1.60,172.16.1.100</DnsServers>
</DomainNameInformation>
<DomainNameInformation>
<DomainName>EXTERNERDOMAINNAME1</DomainName>
<DnsServers>172.16.1.50,172.16.1.60,172.16.1.100</DnsServers>
</DomainNameInformation>
<DomainNameInformation>
<DomainName>EXTERNERDOMAINNAME2</DomainName>
<DnsServers>172.16.1.50,172.16.1.60,172.16.1.100</DnsServers>
</DomainNameInformation>
<RegisterDNS>true</RegisterDNS>
</VPNProfile>
'
$ProfileXML = $ProfileXML -replace '<', '<'
$ProfileXML = $ProfileXML -replace '>', '>'
$ProfileXML = $ProfileXML -replace '"', '"'
$nodeCSPURI = "./Vendor/MSFT/VPNv2"
$namespaceName = "root\cimv2\mdm\dmmap"
$className = "MDM_VPNv2_01"
try
{
$username = Gwmi -Class Win32_ComputerSystem | select username
$objuser = New-Object System.Security.Principal.NTAccount($username.username)
$sid = $objuser.Translate([System.Security.Principal.SecurityIdentifier])
$SidValue = $sid.Value
$Message = "User SID is $SidValue."
Write-Host "$Message"
}
catch [Exception]
{
$Message = "Unable to get user SID. User may be logged on over Remote Desktop: $_"
Write-Host "$Message"
exit
}
$session = New-CimSession
$options = New-Object Microsoft.Management.Infrastructure.Options.CimOperationOptions
$options.SetCustomOption("PolicyPlatformContext_PrincipalContext_Type", "PolicyPlatform_UserContext", $false)
$options.SetCustomOption("PolicyPlatformContext_PrincipalContext_Id", "$SidValue", $false)
try
{
$deleteInstances = $session.EnumerateInstances($namespaceName, $className, $options)
foreach ($deleteInstance in $deleteInstances)
{
$InstanceId = $deleteInstance.InstanceID
if ("$InstanceId" -eq "$ProfileNameEscaped")
{
$session.DeleteInstance($namespaceName, $deleteInstance, $options)
$Message = "Removed $ProfileName profile $InstanceId"
Write-Host "$Message"
} else {
$Message = "Ignoring existing VPN profile $InstanceId"
Write-Host "$Message"
}
}
}
catch [Exception]
{
$Message = "Unable to remove existing outdated instance(s) of $ProfileName profile: $_"
Write-Host "$Message"
exit
}
try
{
$newInstance = New-Object Microsoft.Management.Infrastructure.CimInstance $className, $namespaceName
$property = [Microsoft.Management.Infrastructure.CimProperty]::Create("ParentID", "$nodeCSPURI", "String", "Key")
$newInstance.CimInstanceProperties.Add($property)
$property = [Microsoft.Management.Infrastructure.CimProperty]::Create("InstanceID", "$ProfileNameEscaped", "String", "Key")
$newInstance.CimInstanceProperties.Add($property)
$property = [Microsoft.Management.Infrastructure.CimProperty]::Create("ProfileXML", "$ProfileXML", "String", "Property")
$newInstance.CimInstanceProperties.Add($property)
$session.CreateInstance($namespaceName, $newInstance, $options)
#Zusatzeinbau für Priorisierung IPv4 gegenüber IPv6
if(!(Get-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters -Name DisabledComponents)){
New-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters -Name DisabledComponents -PropertyType DWord -Value 32
}
else{
Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters -Name DisabledComponents -Value 32
}
$Message = "Created $ProfileName profile."
Write-Host "$Message"
}
catch [Exception]
{
$Message = "Unable to create $ProfileName profile: $_"
Write-Host "$Message"
exit
}
$Message = "Script Complete"
Write-Host "$Message"
Wenn ich nun auf einem Notebook mit einem Benutzer einlogge, der lokale Adminrechte auf diesem Notebook hat, läuft das Script durch, der WAN Miniport Adapter in der Netzwerkumgebung wird erstellt und der Tunnel funktioniert nach einem Neustart einwandfrei.
Nun wird dieser WAN Miniport-Adapter aber nicht computerseitig erstellt. D.h. wenn sich nun ein anderer Benutzer einloggt, steht ihm dieser WAN Miniport Adapter und damit der Always On Tunnel nicht zur Verfügung. Der Tunnel ist also nur userseitig für den Benutzer verfügbar, mit dem der Tunnel erstellt wurde.
Nun bin ich hingegangen und hab mir gedacht: Kein Problem, lieber TuXHunT3R, dann machst du ein Loginscript mittels GPO, welches den Tunnel einfach erstellt. Das funktioniert auch, aber nur, wenn der Benutzer auf dem Notebook Adminrechte hat. Wenn nun ein "normaler" Benutzer dieses Script ausführt, wird der Tunnel nicht erstellt, da man zum Erstellen dieses Tunnel lokale Adminrechte braucht. Danke Microsoft, das ist ja wirklich wieder mal super gelöst.... Soviel zum Thema integrierte Lösung....
Nun habe ich verständlicherweise natürlich keine Lust, bei 150 Notebooks dem jeweiligen Benutzer Adminrechte zu geben, das Script händisch auszuführen und dem Benutzer die Adminrechte dann wieder wegzunehmen.
Hat jemand von euch eine Idee, wie man dies schlauer machen könnte? Sodass der Tunnel pro Rechner einmal erstellt wird und dann für jeden Benutzer zur Verfügung steht?
Besten Dank.
Wir setzen Windows 10 1909 Enterprise x64 ein, Update auf das Herbstupdate dieses Jahres ist geplant, sobald sich herausstellt, dass es stabil läuft. AOVPN läuft auf Windows Server 2019.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 613465
Url: https://administrator.de/forum/windows-10-vpn-tunnel-computerseitig-einrichten-613465.html
Ausgedruckt am: 25.12.2024 um 01:12 Uhr
2 Kommentare
Neuester Kommentar
Moin.
Du könntest z.B. im AD oder in einer Datei hinterlegen auf welchem Device für welche User die VPN Verbindung eingerichtet werden soll. Dann im Skript diese Daten auslesen für den jeweiligen Rechner filtern und dann die jeweiligen Usernamen mit einer For-Each-Schleife durchlaufen. Das ganze Skript dann als Computer-Startskript laufen lassen, das läuft per Default im System-Context. Da das Skript ja Impersonation zum Erstellen der User WMI-Profile nutzt ist es kein Problem wenn es im System-Kontext läuft, die Usernamen die das VPN nutzen sollen hast du ja dann schon aus der Datei oder dem AD ausgelesen.
Somit steht dann nach dem Login die VPN Verbindung für jeden User zur Verfügung den du definiert hast.
Gruß w.
https://github.com/MicrosoftDocs/windowsserverdocs/blob/master/WindowsSe ...
Du könntest z.B. im AD oder in einer Datei hinterlegen auf welchem Device für welche User die VPN Verbindung eingerichtet werden soll. Dann im Skript diese Daten auslesen für den jeweiligen Rechner filtern und dann die jeweiligen Usernamen mit einer For-Each-Schleife durchlaufen. Das ganze Skript dann als Computer-Startskript laufen lassen, das läuft per Default im System-Context. Da das Skript ja Impersonation zum Erstellen der User WMI-Profile nutzt ist es kein Problem wenn es im System-Kontext läuft, die Usernamen die das VPN nutzen sollen hast du ja dann schon aus der Datei oder dem AD ausgelesen.
Somit steht dann nach dem Login die VPN Verbindung für jeden User zur Verfügung den du definiert hast.
Gruß w.
Danke Microsoft, das ist ja wirklich wieder mal super gelöst.... Soviel zum Thema integrierte Lösung....
Die wollen den Leuten halt den ConfigMgr / Cloud-Gedöhns und MDMs andrehen. Siehehttps://github.com/MicrosoftDocs/windowsserverdocs/blob/master/WindowsSe ...
However, this does not work in Configuration Manager because you cannot run the package in the end users' context. Therefore, this script uses the Common Information Model to create a WMI session in the user's context, and then it creates a new instance of the MDM_VPNv2_01 WMI class in that session. This WMI class uses the WMI-to-CSP bridge to configure the VPNv2 CSP. Therefore, by adding the class instance, you configure the CSP.
[!IMPORTANT] WMI-to-CSP bridge requires local admin rights, by design. To deploy per user VPN profiles you should be using Configuration Manager or MDM.