OpenVPN LDAP plugin i.c.m. AD probleem

[keranoz]

Hoi,

Ik ben nu al twee dagen bezig om OpenVPN users te laten authenticaten en authorisen via Active Directory, maar krijg dit niet voor elkaar. Die plugin lijkt een beetje raar.

Ik heb al gigantisch veel gegoogled maar volgens mij is de situatie die ik heb hier vrij specifiek, ik kom er niet uit.

De situatie is zo, er zijn 5 OU's waar gebruikers in zitten, en gebruikers moeten lid zijn van een vpn group om verbinding te mogen maken via OpenVPN.

Als voorbeeld even example.local

example.local
  |
  |  --> example |
  |              | --> Mensen |
  |              |             | --> Team1
  |              |             | --> Team2
  |              |             | --> ... (door tot 12)
  | 
  |  --> Andere_ou |
  |                | --> watanders |
  |                |               | --> Mensen
  |                |
  |                | --> nogwatanders |
  |                |                  | --> Mensen
  |                |
  |                | --> ... (nog 3 meer) |
  |                |                      | --> Mensen 
  |
  | --> Users |
  |           | --> vpn

Ik hoop dat het duidelijk is zo. In alle de teams zitten users, en in de OU's genaamd "Mensen" ook. De groep "vpn" is waar users lid van moeten zijn om te mogen connecten.

Nu heb ik het voor elkaar dat mensen ge-authenticate worden, maar ik krijg het het authorisen niet voor elkaar, ik heb nu dit (1 van de authorization blocks)

<Authorization>
        BaseDN                          "ou=Mensen,ou=watanders,ou=Andere_ou,dc=example,dc=local"
        SearchFilter                    "sAMAccountName=%u"
        RequireGroup                    true
        <Group>
                BaseDN                  "cn=vpn,ou=Users,dc=example,dc=local"
                SearchFilter            "sAMAcountName=%u"
                MemberAttribute         "uniqueMember"
        </Group>
</Authorization>

Maar, dit werkt niet. Kan iemand mij hier verder bij helpen?

[Question Mark]

Wat werkt er niet, welke foutmelding krijg je en wat had je verwacht?

[Felyrion]

Volgens mij klopt je searchfilter niet zoals je die hebt staan in je <Group> section.

Moet dat niet naar het groepslidmaatschap verwijzen middels een LDAP Query vorm?
dus iets als
BaseDN "dc=example,dc=local"
SearchFilter "memberOf=CN=vpn, CN=Users, DC=example, DC=local"
MemberAttribute "Member"

Ik zal later eens kijken hoe het hier staat.. is volgens mij geen heel bijzondere constructie.

En probeer anders eerst eens gebruikers toegang te geven die lid zijn van één ou, dan weet je zeker dat dat wel gewoon werkt.

[ Voor 14% gewijzigd door Felyrion op 19-10-2016 13:49 ]

[HollowGamer]

Het is misschien wat meer werk, maar wat is er mis met gewoon certificaten uitdelen? Je hebt daarover veel meer controle en de AD blijft gewoon voor de authenticatie van de user, policies, etc.
Een certificaat aanmaken per device, en je kunt deze terug trekken bij problemen. In theorie zou iemand op één dezelfde device kunnen inloggen op een ander account, al weet ik niet wat daar de policy van is.

Welke plugin gebruik je btw.?

[keranoz]

Question Mark schreef op woensdag 19 oktober 2016 @ 13:18:
Wat werkt er niet, welke foutmelding krijg je en wat had je verwacht?

Sorry, had het er inderdaad bij moeten zetten. Ik krijg de volgende melding in de OpenVPN log:

LDAP search failed: No such object (0000208D: NameErr: DSID-0310020A, problem 2001 (NO_OBJECT), data 0, best match of:
        'DC=example,DC=local'
)
Thu Oct 20 12:22:42 2016 x.x.x.x:57687 PLUGIN_CALL: plugin function PLUGIN_AUTH_USER_PASS_VERIFY failed with status 1: /usr/lib/openvpn/openvpn-auth-ldap.so
Thu Oct 20 12:22:42 2016 x.x.x.x:57687 TLS Auth Error: Auth Username/Password verification failed for peer

Als ik "RequireGroup" op false zit in de config krijg ik de melding ook maar krijg ik wel een werkende verbinding.

Felyrion schreef op woensdag 19 oktober 2016 @ 13:46:
Volgens mij klopt je searchfilter niet zoals je die hebt staan in je <Group> section.

Moet dat niet naar het groepslidmaatschap verwijzen middels een LDAP Query vorm?
dus iets als
BaseDN "dc=example,dc=local"
SearchFilter "memberOf=CN=vpn, CN=Users, DC=example, DC=local"
MemberAttribute "Member"

Ik zal later eens kijken hoe het hier staat.. is volgens mij geen heel bijzondere constructie.

En probeer anders eerst eens gebruikers toegang te geven die lid zijn van één ou, dan weet je zeker dat dat wel gewoon werkt.

Dit had geprobeerd, met "memberOf" en "memberof", had gelezen dat AD hier wel eens moeilijk om doet.
Heb er nu dit van gemaakt:

        <Group>
                BaseDN                  "dc=example,dc=local"
                SearchFilter            "cn=vpn,cn=Users,dc=example,dc=local"
                MemberAttribute         "member"
        </Group>

Krijg dan de volgende melding in OpenVPN log:

LDAP search failed: Operations error (000004DC: LdapErr: DSID-0C0906E8, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v1db1)
Thu Oct 20 12:29:54 2016 x.x.x.x:64084 PLUGIN_CALL: plugin function PLUGIN_AUTH_USER_PASS_VERIFY failed with status 1: /usr/lib/openvpn/openvpn-auth-ldap.so
Thu Oct 20 12:29:54 2016 x.x.x.x:64084 TLS Auth Error: Auth Username/Password verification failed for peer

HollowGamer schreef op woensdag 19 oktober 2016 @ 14:06:
Het is misschien wat meer werk, maar wat is er mis met gewoon certificaten uitdelen? Je hebt daarover veel meer controle en de AD blijft gewoon voor de authenticatie van de user, policies, etc.
Een certificaat aanmaken per device, en je kunt deze terug trekken bij problemen. In theorie zou iemand op één dezelfde device kunnen inloggen op een ander account, al weet ik niet wat daar de policy van is.

Welke plugin gebruik je btw.?

We willen zowel certificaten als username en password zodat elke gebruiker iets (versschillends, de certs) moet hebben, ÉN iets moet weten (username en password). Hiermee voorkom je dus dat ietmand zo maar hetwerk opkomt door ff te dubbelklikken op dat OpenVPN icoontje in de taakbalk.

En zoals je misschien gezien hebt in de logs hierboven gebruik ik de OpenVPN LDAP plugin. (Niet de PAM plugin)

EDIT: oh, en eh, het draait allemaal op een Debian 8 machine. Zowel de plugin als OpenVPN zelf gewoon geïnstalleerd d.m.v. apt.

[mbaltus]

De melding in de VPNLog duidt er volgens mij op dat je probleem zit in dat je bind met de AD niet lukt en niet dat de query zelf mislukt (dus dat je niemand kan vinden). De query kan daardoor uberhaupt niet uitgevoerd worden.

[Felyrion]

In je laatste voorbeeld heb je geen ou meer in je baseDN, volgens mij kan dat niet. Probeer hetzelfde nog eens met

        <Group>
                BaseDN                  "ou=Andere_ou,dc=example,dc=local"
                SearchFilter            "cn=vpn,cn=Users,dc=example,dc=local"
                MemberAttribute         "member"
        </Group>

of de juiste ou.

edit:
Check ook deze: https://github.com/SpriteLink/NIPAP/issues/736
Vergelijkbaar issue lijkt me

[ Voor 11% gewijzigd door Felyrion op 20-10-2016 14:48 ]

[keranoz]

mbaltus schreef op donderdag 20 oktober 2016 @ 13:16:
De melding in de VPNLog duidt er volgens mij op dat je probleem zit in dat je bind met de AD niet lukt en niet dat de query zelf mislukt (dus dat je niemand kan vinden). De query kan daardoor uberhaupt niet uitgevoerd worden.

Het werkt wel als ik de group requirement op false zet, krijg dan de melding wel, maar verbinding opbouwen lukt en VPN werkt. Volgens mij is het goed bewijs dat de verbinding met AD werkt dat ik er niet in kom als ik met een fout wachtwoord inlog en ik er wel in kom met een goed wachtwoord.

Volgens mij heeft deze melding te maken met het feit dat er geen OU in de BaseDN is opgegeven, zie hieronder:

Felyrion schreef op donderdag 20 oktober 2016 @ 14:21:
In je laatste voorbeeld heb je geen ou meer in je baseDN, volgens mij kan dat niet. Probeer hetzelfde nog eens met

        <Group>
                BaseDN                  "ou=Andere_ou,dc=example,dc=local"
                SearchFilter            "cn=vpn,cn=Users,dc=example,dc=local"
                MemberAttribute         "member"
        </Group>

of de juiste ou.

edit:
Check ook deze: https://github.com/SpriteLink/NIPAP/issues/736
Vergelijkbaar issue lijkt me

Een probleem is dat er meerdere OU's zijn waar users in zitten, er is dus volgens mij geen "juiste" OU om elke gebruiker te vinden. Ik heb dit nu opgelost in de LDAP config door 5 van deze authorization blocks met elke een andere BaseDN om in te zoeken, en dit lijkt te werken, de OU waar ik zelf in zit is de laatste van de 5. Heb nu in het laatste authorization block de Group zo aangepast zoals u zei en hier het resultaat:

Thu Oct 20 15:59:26 2016 x.x.x.x:64924 PLUGIN_CALL: plugin function PLUGIN_AUTH_USER_PASS_VERIFY failed with status 1: /usr/lib/openvpn/openvpn-auth-ldap.so
Thu Oct 20 15:59:26 2016 x.x.x.x:64924 TLS Auth Error: Auth Username/Password verification failed for peer

De melding is een stuk kleiner en geen grote errors meer. Het lijkt er nu op dat het checken of de user in de vpn groep zit gewoon niet goed gaat op de één of andere manier.

Dat probleem op Github leek opgelost te zijn door een OU toe te voegen aan de BaseDN, maar jammergenoeg is er meer voor nodig bij mij

[keranoz]

Ben nu een paar weken verder, maar ik ben er nog steeds niet uit.

Is er echt niemand die mij hier verder mee kan helpen?

Even een samenvatting:

OpenVPN op een voor de rest kale Debian server i.c.m. LDAP authenticatie/authorisatie i.c.m. Active Directory krijg ik niet werken. Volgens google kun je als base DN bijvoorbeeld "dc=contososo,dc=com" meegeven maar dat werkt bij mij niet. Dan krijg ik een foutmelding. Het lijkt alleen te werken als ik een ou meegeef, zoals "ou=gebruikers,dc=contoso,dc=com". Maar dat wil ik niet, want ik heb gebruikers in verschillende OU's zitten.

[Semt-x]

extra optie meegeven?
BaseDN "dc=contososo,dc=com"
Scope "Subtree"

[keranoz]

Semt-x schreef op dinsdag 15 november 2016 @ 13:45:
extra optie meegeven?
BaseDN "dc=contososo,dc=com"
Scope "Subtree"

Mocht niet baten jammergenoeg

Auth-LDAP Configuration Error: Scope key is unknown (/etc/openvpn/auth/ldap.conf:12).
A parse error occured while attempting to read your configuration file.
Tue Nov 15 13:47:22 2016 PLUGIN_INIT: plugin initialization function failed: /usr/lib/openvpn/openvpn-auth-ldap.so

[keranoz]

Semt-x schreef op dinsdag 15 november 2016 @ 13:45:
extra optie meegeven?
BaseDN "dc=contososo,dc=com"
Scope "Subtree"

Mocht niet baten jammergenoeg

Auth-LDAP Configuration Error: Scope key is unknown (/etc/openvpn/auth/ldap.conf:12).
A parse error occured while attempting to read your configuration file.
Tue Nov 15 13:47:22 2016 PLUGIN_INIT: plugin initialization function failed: /usr/lib/openvpn/openvpn-auth-ldap.so

[ElCondor]

Haal je niet OU en Group membership door de war. OU is alleen maar een logische verdeling in AD. 'Membership' van een OU zou niks uit moeten maken. Als je gewoon de root van je AD als Base DN neemt en dan vervolgens Groupmembership als filter opgeeft. Dan worden vanaf de BaseDN alle user accounts gechecked op Groupmembership. Of zie ik het nu te simpel?
Lidmaatschap van een OU moet je niet als security group zien, lijkt me

-edit- of is dit nu precies wat Semt-x bedoeld?

[ Voor 5% gewijzigd door ElCondor op 15-11-2016 14:15 ]

[keranoz]

ElCondor schreef op dinsdag 15 november 2016 @ 14:15:
Haal je niet OU en Group membership door de war. OU is alleen maar een logische verdeling in AD. 'Membership' van een OU zou niks uit moeten maken. Als je gewoon de root van je AD als Base DN neemt en dan vervolgens Groupmembership als filter opgeeft. Dan worden vanaf de BaseDN alle user accounts gechecked op Groupmembership. Of zie ik het nu te simpel?
Lidmaatschap van een OU moet je niet als security group zien, lijkt me

-edit- of is dit nu precies wat Semt-x bedoeld?

Dat is ook precies wat ik wil, maar dat werkt niet, gewon de root van AD als BaseDN accepteerd hij niet om de een of andere reden. Hij accepteerd "ou=Gebruikers,dc=contoso,dc=com" wel, maar "dc=contoso,dc=com" niet. krijg dan de melding:

LDAP search failed: Operations error (000004DC: LdapErr: DSID-0C0906E8, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v1db1)"

Die melding klinkt mij totaal niet logisch, aangezien de user waarmee ik bind gewoon goed is, en als ik de precieze OU opgeef ik waar ik zelf in sta, werkt het ook (of één OU megeef in de bind waar ik zelf in zit, maar dan twee niveau's dieper (zie "tekening" in OP). Maar wij hebben gebruikers in meerdere OU's...

Edit: de ldap config is nu zo:

<LDAP>
        URL                             ldap://dc2.example.local:389
        BindDN                          "example\openvpnldap"
        Password                        password
        Timeout                         15
        TLSEnable                       no
        FollowReferrals                 yes
</LDAP>

<Authorization>
        BaseDN                          "dc=example,dc=local"
        SearchFilter                    "sAMAccountName=%u"
        RequireGroup                    true
        <Group>
                BaseDN                  "cn=Users,dc=example,dc=local"
                SearchFilter            "(cn=vpn)"
                MemberAttribute         "member"
        </Group>
</Authorization>

[ Voor 34% gewijzigd door keranoz op 15-11-2016 14:48 ]

[ElCondor]

Heeft de user waarmee je bindt wel rechten op de betreffende OU in AD? Lukt het ook als ej een andere losse OU selecteerd? -edit- dat lukt dus... Dan zou je bijna denken dat je de te gebruiken OU's allemaal nog apart in één overkoepelende OU zou moeten steken en DIE opgeven als BaseDN. Het lijkt bijna op een bug

Je zou voor iedere OU die je wilt checken een losse bind kunnen doen (geen idee of dat echt mogelijk is, maar ik zit er aan te denken als een soort dirty workaround).

[ Voor 3% gewijzigd door ElCondor op 15-11-2016 15:07 ]

[keranoz]

ElCondor schreef op dinsdag 15 november 2016 @ 15:06:
Heeft de user waarmee je bindt wel rechten op de betreffende OU in AD? Lukt het ook als ej een andere losse OU selecteerd? -edit- dat lukt dus... Dan zou je bijna denken dat je de te gebruiken OU's allemaal nog apart in één overkoepelende OU zou moeten steken en DIE opgeven als BaseDN. Het lijkt bijna op een bug

Je zou voor iedere OU die je wilt checken een losse bind kunnen doen (geen idee of dat echt mogelijk is, maar ik zit er aan te denken als een soort dirty workaround).

Ik vind het ook erg lijken op een bug. Rechten zijn het probleem niet denk ik, ik lees overal dat de user waarmee je bind geen rechten nodig heeft, maar ik heb voor de grap de user even domain admin gemaakt, maar dat hielp ook niet.

Ik heb al geprobeerd om meerdere authorization blocks te maken inderdaad. Dit werkt tot zo ver dat die automatisch het goede block pakt voor de gebruiker. Maar, als iemand anders dan wil inloggen die in een andere OU zit en er dus een andere authorization block nodig is, werkt dat niet.

Een allegebruikers in één OU plakken heb ik over na zitten denken, maar ik ben bang dat dat de hele structuur omgooid, er zijn heel veel dingen die hiermee werken, naast een hybride local AD/Office 365 omgeving.

[Semt-x]

hardcoded paden zijn een kenmerk van jaren 90 programma's.
maar is het searchfilter een LDAP query? dan zou je alle OUs kunnen includen in dat filter:

Searchfilter "(|(cn=vpn,cn=Users,dc=example,dc=local)(cn=vpn,cn=AndereUsers,dc=example,dc=local))"

[ElCondor]

Ik ben toch bang dat je er niet aan gaat ontkomen om de GEHELE AD user tree in één overkoepelende OU te steken en deze OU de BaseDN te maken. Wel een behoorlijk ingrijpende verandering, maar volgens mij de meest makkelijke om te implementeren.

[keranoz]

Semt-x schreef op dinsdag 15 november 2016 @ 15:48:
hardcoded paden zijn een kenmerk van jaren 90 programma's.
maar is het searchfilter een LDAP query? dan zou je alle OUs kunnen includen in dat filter:

Searchfilter "(|(cn=vpn,cn=Users,dc=example,dc=local)(cn=vpn,cn=AndereUsers,dc=example,dc=local))"

Ja dat ben ik met je eens, maar ik wil graag alles proberen. Het searchfilter heb ik volgens mij nog weinig aan. Zoals ik het begrijp kun je een search filter zoeken in en onder de BaseDN. Maar dat is al te ver. Ik heb eigenlijk meerdere BaseDN's nodig denk ik, aangezien "dc=example,dc=local" niet geaccepteerd wordt, maar "ou=gebruikers,dc=example,dc=local" wel. Maar er zitten ook gebruikers in "ou=example,dc=example,dc=local".

Ik zie trouwens dat je volgens mij niet helemaal begrijpt wat ik bedoel. Of kan "cn=vpn,cn=AndereUsers,dc=example,dc=local" kijken of de gebruiker lid is van de group VPN, die te vinden is in de BaseDN, en de gebruiker dan zoeken in "cn=AndreUsers,dc=example,dc=local" (en anderen zoals je zei)? Er is namelijk maar 1 vpn groep en die staat in "ou=Users,dc=example,dc=local"

Ook snap ik het verschil niet goed tusen een ou en een cn, een cn is meer een object wat ik zo lees, terwijl een organizational unit gewoon een "map" is waar je meer mee kunt. Maar de termen worden volgens mij redelijk door elkaar gebruikt in LDAP, zo werkt "ou=Gebruikers,dc=example,dc=local", maar "cn=Gebruikers,dc=example,dc=local" ook...

ElCondor schreef op dinsdag 15 november 2016 @ 15:53:
Ik ben toch bang dat je er niet aan gaat ontkomen om de GEHELE AD user tree in één overkoepelende OU te steken en deze OU de BaseDN te maken. Wel een behoorlijk ingrijpende verandering, maar volgens mij de meest makkelijke om te implementeren.

Ja dat vrees ik ook, maar het frusteerd mij dat "dc=example,dc=local" niet werkt. Terwijl ik hier als ik Google wel veel over lees, en dat het zou moeten werken. Doet mij denken dat er iets mis is met de OpenVPN LDAP plugin.

[ Voor 45% gewijzigd door keranoz op 15-11-2016 16:10 ]

[ElCondor]

Probeer het gewoon eens met een of twee OU's. Dan kun je testen of het in ieder geval werkt. Mocht dat dan zo zijn, dan zou ik een bugreport melden en kijken wat ze daar op zeggen. Ik weet niet of er een ongeschreven regel is dat users altijd in één overkoepelende OU moeten zitten, maar het lijkt erop dat OpenVPN dit afdwingt.

Succes er mee in ieder geval.

[Semt-x]

Ik heb je post maar half gelezen, je zou een Searchfilter kunnen maken met die 5 OU's waar users in staan, op de manier die ik in mijn eerdere post voorstelde.
De "subtree" van een ldap query is de enige manier om een scope te bepalen. en levert precies wat jij wil. Misschien heet het geen "scope" maar anders binnen openvpn, als ze dan toch van een standaard afwijken, zou het best kunnen ?

Dit is de prijs die wordt betaald voor een belabberd OU ontwerp in combinatie met een beroerde AD koppeling in een applicatie OpenVPN in dit geval.

het verschil tussen cn en ou:
cn=Users, cn staat voor container de standaard users map is een container.
ou=domain controllers, de domain controller computer objecten staan in een OU.
aan een OU kun je een group policy koppelen aan een cn niet.

[HollowGamer]

Blijf de beste oplossing gewoon certificaat uitdelen aan device, met VPN-connectie maken (kan ook vanaf lock/aanmeld-screen en zelfs automatisch d.m.v. service), daarna pas inloggen/checken AD.

Een VPN heeft niks met een AD te maken, en je maakt daardoor alles wel heel ingewikkeld.
Sterker nog, het gevaar zit erin dat ik op elk willekeurig op jullie netwerk kan komen als ik de login weet van de gebruiker.

Wil je dit allemaal niet, dan zou ik kijken naar iets als Citrix.

[ Voor 3% gewijzigd door HollowGamer op 15-11-2016 20:14 ]

[keranoz]

Semt-x schreef op dinsdag 15 november 2016 @ 18:17:
Ik heb je post maar half gelezen, je zou een Searchfilter kunnen maken met die 5 OU's waar users in staan, op de manier die ik in mijn eerdere post voorstelde.
De "subtree" van een ldap query is de enige manier om een scope te bepalen. en levert precies wat jij wil. Misschien heet het geen "scope" maar anders binnen openvpn, als ze dan toch van een standaard afwijken, zou het best kunnen ?

Dit is de prijs die wordt betaald voor een belabberd OU ontwerp in combinatie met een beroerde AD koppeling in een applicatie OpenVPN in dit geval.

het verschil tussen cn en ou:
cn=Users, cn staat voor container de standaard users map is een container.
ou=domain controllers, de domain controller computer objecten staan in een OU.
aan een OU kun je een group policy koppelen aan een cn niet.

Ben het met je eens dat OU ontwerp beter had gekunt, maar helaas kunnen wij daar nu weinig meer aan doen.

Ik kan helemaal niks vinden over een "scope" achtig iets binnen OpenVPN LDAP.

Ik ga nu kijken naar een andere oplossing, als die er is stappen we hier vanaf. Zo niet, verder puzzelen.

HollowGamer schreef op dinsdag 15 november 2016 @ 20:14:
Blijf de beste oplossing gewoon certificaat uitdelen aan device, met VPN-connectie maken (kan ook vanaf lock/aanmeld-screen en zelfs automatisch d.m.v. service), daarna pas inloggen/checken AD.

Een VPN heeft niks met een AD te maken, en je maakt daardoor alles wel heel ingewikkeld.
Sterker nog, het gevaar zit erin dat ik op elk willekeurig op jullie netwerk kan komen als ik de login weet van de gebruiker.

Wil je dit allemaal niet, dan zou ik kijken naar iets als Citrix.

Dat laatste is niet waar. Wij willen certificaat + login, dus iets wat je moet hebben, en iets dat je moet weten. Het inloggen voorkomt bijvoorbeeld dat als jij even wegloopt van je PC zonder te locken, iemand anders zomaar een VPN verbinding kan opbouwen.

[HollowGamer]

KeRaNoZ schreef op woensdag 16 november 2016 @ 10:35:
Dat laatste is niet waar. Wij willen certificaat + login, dus iets wat je moet hebben, en iets dat je moet weten. Het inloggen voorkomt bijvoorbeeld dat als jij even wegloopt van je PC zonder te locken, iemand anders zomaar een VPN verbinding kan opbouwen.

Het is toch niet erg dat de VPN connectie kan worden opgezet? Het inloggen en de authenticatie moet daarna toch nog gebeuren? Ja, je hangt daarna in het bedrijfsnetwerk, maar verder dan het lock-screen kom je sowieso niet (tenzij je het lock-screen aanpast, maar dan moet je wel in de BIOS komen + booten met ISO).

Ik neem toch aan dat je applicaties in het bedrijfsnetwerk ook controleert op toegang?

[keranoz]

HollowGamer schreef op woensdag 16 november 2016 @ 11:12:
[...]

Het is toch niet erg dat de VPN connectie kan worden opgezet? Het inloggen en de authenticatie moet daarna toch nog gebeuren? Ja, je hangt daarna in het bedrijfsnetwerk, maar verder dan het lock-screen kom je sowieso niet (tenzij je het lock-screen aanpast, maar dan moet je wel in de BIOS komen + booten met ISO).

Ik neem toch aan dat je applicaties in het bedrijfsnetwerk ook controleert op toegang?

Ja, dat laatste doen we, maar alsnog. Het punt is, je bouwt een VPN verbinding op niet naar een PC, maar naar het hele netwerk. Met een VPN server die we gewoon een route naar het hele netwerk laten pushen.