Een beleid bevat een of meer toegangsregels. Elke regel bestaat uit instellingen die u kunt configureren voor het beheer van gebruikerstoegang tot toepassingsportals als geheel of tot opgegeven webtoepassingen.

Netwerkbereik

U bepaalt de gebruikersbasis voor elke regel door een netwerkbereik op te geven. Een netwerkbereik bestaat uit een of meer IP-bereiken. U maakt netwerkbereiken op het tabblad Identiteits- en toegangsbeheer op de pagina Installatie > Netwerkbereiken voordat u toegangsbeleidssets configureert.

Apparaattype

Selecteer het type apparaat dat de regel beheert. De clienttypen zijn Webbrowser, Clientapp voor identiteitsbeheer, iOS, Android en Alle apparaattypen.

Groepen toevoegen

U kunt verschillende beleidsregels toepassen voor verificatie op basis van het lidmaatschap van uw gebruikers. Om groepen gebruikers toe te wijzen om in te loggen via een specifieke verificatiestroom, kunt u groepen toevoegen aan de toegangsbeleidsregel. U kunt groepen synchroniseren vanuit uw bedrijfsdirectory of lokale groepen die u hebt gemaakt in de beheerdersconsole. Groepsnamen moeten uniek zijn binnen een domein.

Om groepen te gebruiken in toegangsbeleidsregels, configureert u een nieuw beleid vanaf de pagina Beheer van directory's > Beleid en selecteert u de gewenste groepen voor het beleid. Het beleid moet worden toegewezen op de pagina Gebruikerskenmerken en vervolgens met de directory worden gesynchroniseerd.

Wanneer groepen worden gebruikt in een toegangsbeleidsregel, verandert de gebruikersaanmelding voor de gebruiker. In plaats van gebruikers te vragen hun domein te selecteren en vervolgens hun inloggegevens in te voeren, wordt een pagina weergegeven met de vraag om hun unieke ID in te voeren. Directories Management vindt de gebruiker in de interne database op basis van de unieke ID en geeft de verificatiepagina weer die in die regel is geconfigureerd.

Wanneer een groep niet is geselecteerd, is de toegangsbeleidsregel van toepassing op alle gebruikers. Wanneer u toegangsbeleidsregels configureert die regels op basis van groepen en een regel voor alle gebruikers omvatten, moet u ervoor zorgen dat de regel die voor alle gebruikers is ingesteld de laatste regel is die wordt vermeld in het gedeelte Beleidsregels van het beleid.

Raadpleeg de documentatie van VMware Identity Manager over Inlogervaring met behulp van de unieke identificatie voor meer informatie over hoe regels op gebruikers worden toegepast.

Verificatiemethoden

Stel de prioriteit van de verificatiemethoden voor de beleidsregel in. De verificatiemethoden worden toegepast in de volgorde waarin ze worden weergegeven. De eerste identiteitsproviderinstantie die voldoet aan de verificatiemethode en de netwerkbereikconfiguratie in het beleid, wordt geselecteerd, en de gebruikersverificatieaanvraag wordt naar de identiteitsproviderinstantie doorgestuurd voor verificatie. Als de verificatie mislukt, wordt de volgende verificatiemethode in de lijst geselecteerd. Als certificaatverificatie wordt gebruikt, moet deze methode de eerste verificatiemethode in de lijst zijn.

U kunt toegangsbeleidsregels configureren om te eisen dat gebruikers verificatiegegevens via twee verificatiemethoden opgeven voordat ze zich kunnen aanmelden. Als een of beide verificatiemethoden mislukken en er ook alternatieve methoden zijn geconfigureerd, dan worden de gebruikers gevraagd om hun verificatiegegevens in te voeren voor de volgende verificatiemethoden die zijn geconfigureerd. De volgende twee scenario's beschrijven hoe verificatieketens werken.

  • In het eerste scenario is de toegangsbeleidsregel geconfigureerd zodat gebruikers verificatie moeten uitvoeren met hun wachtwoord en hun Kerberos-verificatiegegevens. Alternatieve verificatie wordt ingesteld om het wachtwoord en de RADIUS-verificatiegegevens te vereisen voor verificatie. Een gebruiker voert het wachtwoord correct in, maar voert niet de juiste Kerberos-verificatiegegevens in. Omdat de gebruiker het juiste wachtwoord heeft ingevoerd, geldt de alternatieve verificatieaanvraag alleen voor de RADIUS-verificatiegegevens. De gebruiker moet het wachtwoord niet opnieuw invoeren.
  • In het tweede scenario is de toegangsbeleidsregel geconfigureerd zodat gebruikers verificatie moeten uitvoeren met hun wachtwoord en hun Kerberos-verificatiegegevens. Alternatieve verificatie wordt ingesteld om RSA SecurID en een RADIUS te vereisen voor verificatie. Een gebruiker voert het wachtwoord correct in, maar voert niet de juiste Kerberos-verificatiegegevens in. De alternatieve verificatieaanvraag geldt zowel voor de RSA SecurID-verificatiegegevens als voor de RADIUS-verificatiegegevens.

Lengte van verificatiesessie

Voor elke regel stelt u de lengte in waarin deze verificatie geldig is. De waarde bepaalt de maximale hoeveelheid tijd waarover gebruikers sinds hun laatste verificatiegebeurtenis beschikken om toegang te krijgen tot hun portaal of om een specifieke webtoepassing te starten. Een waarde van 4 in een webtoepassingsregel bijvoorbeeld geeft gebruikers vier uur tijd om de webtoepassing te starten tenzij ze een andere verificatiegebeurtenis starten die de tijd verlengt.

Aangepast toegang geweigerd-bericht

Wanneer gebruikers zich proberen aan te melden en dit mislukt als gevolg van ongeldige verificatiegegevens, een onjuiste configuratie of een systeemfout, wordt een toegang geweigerd-bericht weergegeven. Het standaardbericht is
Toegang geweigerd omdat geen geldige verificatiemethoden zijn gevonden.
U kunt een aangepast foutbericht maken voor elke toegangsbeleidsregel, die het standaardbericht vervangt. Het aangepaste bericht kan tekst bevatten en een koppeling voor een bericht met een actieverzoek. Als bijvoorbeeld in een beleid voor het beheren van mobiele apparaten een gebruiker zich probeert aan te melden met een niet-geregistreerd apparaat, kan het volgende aangepaste foutbericht worden weergegeven:
Registreer uw apparaat om toegang te krijgen tot bedrijfsbronnen door te klikken op de koppeling aan het einde van dit bericht. Neem contact op met ondersteuning voor hulp als uw apparaat al is geregistreerd.

Voorbeeld van standaardbeleid

Het volgende beleid dient als voorbeeld van hoe u het standaardbeleid kunt configureren voor het beheer van toegang tot de toepassingsportal. Zie Het toegangsbeleid voor gebruikers beheren.

De beleidsregels worden geëvalueerd in de weergegeven volgorde. U kunt de volgorde van het beleid wijzigen door de regel in de sectie Beleidsregels te slepen en neer te zetten.

In de volgende use case wordt dit beleidsvoorbeeld gebruikt voor alle toepassingen.

    • Voor het interne netwerk (intern netwerkbereik) worden twee verificatiemethoden geconfigureerd voor de regel, namelijk Kerberos en wachtwoordverificatie als de alternatieve methode. Om toegang tot het portaal met apps te krijgen vanaf een intern netwerk, probeert de service eerst gebruikers te verifiëren met Kerberos-verificatie, omdat dit de eerste verificatiemethode is die in de regel wordt weergegeven. Als dit mislukt, worden de gebruikers gevraagd om hun Active Directory-wachtwoord in te voeren. Gebruikers melden zich aan met een browser en hebben nu toegang tot hun gebruikersportalen voor een sessie van acht uur.
    • Voor toegang vanaf het externe netwerk (alle bereiken) wordt slechts één verificatiemethode geconfigureerd, namelijk RSA SecurID. Om toegang tot het portaal met apps te krijgen vanaf een extern netwerk, moeten gebruikers zich aanmelden met SecurID. Gebruikers melden zich aan met een browser en hebben nu toegang tot hun portalen met apps voor een sessie van vier uur.
  1. Als een gebruiker toegang probeert te krijgen tot een bron, behalve voor webtoepassingen die worden gedekt door een webtoepassingsspecifiek beleid, is het standaardportaaltoegangsbeleid van toepassing.

    De tijd voor herverificatie voor dergelijke bronnen bijvoorbeeld komt overeen met de tijd voor herverificatie van de beleidsregel voor standaardtoegang. Als de tijd voor een gebruiker die zich bij het portaal met apps aanmeldt, acht uur is volgens de standaardtoegangsbeleidsregel, en de gebruiker probeert een bron te starten tijdens de sessie, dan wordt de toepassing opgestart zonder dat de gebruiker zich opnieuw moet verifiëren.