Användarhantering
Hantering av användare
Användare kan skapas både manuellt och automatiskt via SAML 2-autentisering. För att starta processen:
- Skapa användarmappar: Skapa först mappar i modulen Användare för att organisera användare. Detta kräver en användarmall med koden "admin".
- Lägg till användare: Med mallen på plats kan du börja lägga till användare:
- Öppna vyn Behörigheter från administrationsgränssnittet.
- Välj "Användare och roller" i trädfönstret.
- Klicka på "Ny mapp" i visningsmenyn.
- När du har namngett mappen, tilldelat behörigheter och sparat mappen visas den i behörighetsträdet.
- Lägg sedan till administratörsmallen som en tillåten mall, ange en kod för mappen och spara igen.

Manuell skapande av användare
Så här skapar du en användare manuellt:
- Navigera till lämplig mapp.
- Välj "Ny användare" för att öppna Efecte-användarvyn.
- Ge den nya användaren ett namn.
- Fyll i den information som krävs (om någon).
- Klicka på Spara.

Informationen om den nya användaren visas i ESM-innehållsområdet och namnet på den nya användaren visas under den aktiva mappen i behörighetsträdet.
Automatisk hantering av användare
Automatisk skapande, uppdatering och borttagning av användare kan orkestreras med hjälp av Efecte Provisioning Engine (EPE) genom att använda en Orchestration-nod i arbetsflödena. Se EPE-dokumentationen för mer information.
Användarspecifika inställningar
Användarspecifika inställningar möjliggör anpassning av autentiseringsmetoder och gränssnittsinställningar, inklusive språk och tidszon. Dessa inställningar är unika för varje användare.
Klicka på Inställningar i visningsmenyn för att öppna vyn Användarinställningar:

Användarspecifika säkerhetsinställningar
- Autentiseringsmetod: Välj mellan ID/lösenord ( annat ), LDAP AD -baserad eller SAML 2- autentisering. Varje metod har sina egna specifikationer för matchning av användar-ID och rolltilldelning.
- a. Om Annan autentiseringsmetod väljs kan ESM-användaren autentiseras antingen lokalt med användar-ID/lösenord lagrat i databasen eller med NTSM-autentisering med användar-ID lagrat i databasen eller med användar-ID hämtat via LDAP-gränssnittet.
- Vanligtvis använder LDAP- autentisering Windows Active Directory . Du måste ange LDAP-inställningarna (vanligtvis LDAP-servrar) under avsnittet Inställningar för pluggbar autentisering i plattformsinställningarna (redigerbara via Administration > Underhåll > Redigera inställningar).
- OBS! Om LDAP-autentisering används måste användarens Efecte-användar-ID matcha ett befintligt användar-ID i LDAP-systemet, och LDAP måste läggas till som det första värdet i plattformsinställningen auth.chain. Den användarspecifika LDAP-inställningen som konfigurerats i vyn Användarspecifika säkerhetsinställningar kan åsidosättas med plattformsinställningen auth.chain.
- Om andra autentiseringsmetoder (t.ex. databas eller ntlm) listas i auth.chain-värdet före LDAP, kommer autentisering först att försökas med dem, oavsett inställningen i användarens säkerhetsinställningsvy.
- Om LDAP saknas i värdet auth.chain kommer LDAP-autentisering aldrig att försökas, oavsett inställningen i användarens säkerhetsinställningsvy.
- När SAML 2 -autentisering är aktiverad tilldelas rollerna för en ESM-användare enligt de roller som identifieras i SAML 2-meddelandena.
- När SAML 2-autentisering används är det inte möjligt att tilldela roller i ESM-administrationsgränssnittet till en användare manuellt, utan endast via SAML 2-meddelandet.
- OBS! Externa ID:n som identifierar rollerna måste mappas till ESM-roller i rollredigeringsvyn.
- ESM-användar-ID och lösenord: För lokal autentisering, ange användar-ID och lösenord.
- Observera att endast root-användaren har tillåtelse att ändra användar-ID:n.
- ESM-användarnivå: Alternativen inkluderar:
- Normal – Visa, redigera och ta bort mallar, mappar och datakort enligt användarrollens behörigheter.
- Skrivskyddad – Läs datakort enligt användarrollens behörigheter.
- Root - obegränsade rättigheter till ESM-data och dataunderhåll, utan några begränsningar för användarroller.
- Använd root-användarnivån försiktigt, eftersom den är exceptionellt kraftfull.
Användarens tidszoninställningar
Genom att aktivera multiple.timezone.support kan användare ställa in sin föredragna tidszon, vilket förbättrar den globala användbarheten hos ESM.

Autentiseringsmetod
Du kan välja om du vill autentisera användare baserat på användar-ID/lösenord (Övrigt), LDAP AD -baserad autentisering (LDAP) eller SAML 2-autentisering ( SAML 2).
Automatisk skapande av användare med SAML 2
SAML 2-autentisering underlättar automatisk användarskapande baserat på attributinformation i SAML 2-meddelanden, och tilldelar roller och användarnivåer därefter. Detta flyttar användarhanteringen (med undantag för rotanvändare) till identitetsleverantören, som Efecte Identity Management (EIM) eller Secure Access ( ESA ).
Observera att om SAML 2-baserad autentisering används för användaren måste hela rollhanteringen hanteras via EIM eller ESA . Även om autentiseringsmetoden ändras manuellt till LDAP, eller nya roller läggs till för användaren, kommer autentiseringen att ändras tillbaka till SAML 2.0 vid nästa inloggning om EIM eller ESA skickar information på användarnivå.
Konfigurera SAML 2-baserad autentisering
Så här använder du SAML 2-baserad autentisering:
- Justera autentiseringskedjan i plattformsinställningarna för att inkludera SAML 2.
- Konfigurera identitetsleverantören för att skicka obligatoriska attribut via Shibboleth.
- §roller - lista över roller som strängar separerade med tecknet ';'.
- esm_userLevel - möjliga värden Rot, Normal, Skrivskyddad, Ingen åtkomst.
- esm_email - Obligatorisk för att skapa en person.
- esm_firstName - För att skapa person, valfritt.
- esm_lastName - För att skapa person, valfritt.
- Mappa ESM-roller till de som identifierats via SAML 2 i rollredigeraren.

Rollmappning i rollredigeringsvyn:

Konfigurera NTLM-autentisering (lokal)
NTLM-autentisering gäller endast för lokala installationer och tillåter användare att logga in med sina Windows-inloggningsuppgifter.
Obs! Detta gäller endast för ESM-installationer på plats.
Om ESM är konfigurerat för att använda NTLM HTTP-autentisering kan användare logga in på ESM med sina Windows-inloggningsuppgifter utan att behöva ange användarnamn och lösenord igen (när de väl är inloggade på sin Windows-arbetsstation). NTLM HTTP-autentisering är ett utmanings-/svarsprotokoll: servern skickar en utmaning till klienten (dvs. webbläsaren), och servern och klienten svarar via HTTP.
ESM stöder både NTLMv1- och NTLMv2-protokoll. Det äldre v1-protokollet rekommenderas inte längre att använda och fungerar inte ens med standardinställningarna för nyare Windows-arbetsstationer och -servrar. ESM stöder den äldre protokollversionen för bakåtkompatibilitet.
Med inställningen auth.sso.use.fully.qualified.account.name kan ESM konfigureras att jämföra Windows-användarnamn med ESM-användarnamn med hjälp av fullständigt kvalificerat kontonamn (DOMAIN\användarnamn). Denna konfiguration fungerar med alla SSO-autentiseringar: NTLMv1, NTLMv2 och Kerberos. Detta kräver att ESM-användare har sina användar-ID:n i formatet DOMAIN\användarnamn.
Så här använder du NTLM-autentisering i ESM:
- Användare måste ha samma användarnamn i Windows-domänen och ESM.
- NTLM måste konfigureras som en av autentiseringsmetoderna.
- Detta kan göras genom att lägga till värdet negotiate eller NTLM (för NTLMv1) till inställningen auth.chain (från Administration > Underhåll > Redigera inställningar ) – till exempel auth.chain = negotiate, database. Denna exempelkonfiguration aktiverar NTLMv2-autentisering för ESM och gör det till den första autentiseringsmetoden som kommer att testas.
Notera:
De vanligaste konfigurationsvärdena är databas; LDAP, databas; och negotiate, LDAP, databas. Om både NTLM och negotiate konfigureras samtidigt kommer endast negotiate att användas.
Förhandla (eller NTLM) måste vara det första alternativet i listan om det ska användas. Annars 1) om den primära inloggningsmetoden lyckas kommer NTLM-autentisering också att utföras, men den används aldrig i ESM, eller 2) om den primära inloggningsmetoden misslyckas verkar inloggningen lyckas med vilket lösenord som helst, eftersom NTLM-autentisering kommer att användas som reserv, men ingen avisering om detta visas.
- Detta kan göras genom att lägga till värdet negotiate eller NTLM (för NTLMv1) till inställningen auth.chain (från Administration > Underhåll > Redigera inställningar ) – till exempel auth.chain = negotiate, database. Denna exempelkonfiguration aktiverar NTLMv2-autentisering för ESM och gör det till den första autentiseringsmetoden som kommer att testas.
- Endast för NTLMv1: Domänkontrollanter måste konfigureras. Om användare till exempel kan tillhöra en av domänerna SALES och DEVEL måste domänkontrollanterna för båda domänerna anges. Detta görs genom att lägga till följande rader i plattformsinställningarna:
- auth.ntlm.SALES.domänkontroller = salesdc.mittföretag.com
- auth.ntlm.DEVEL.domänkontroller = develdc.mittföretag.com
- Den allmänna formen för den här inställningen är auth.ntlm.<domänens NetBIOS-namn>.domaincontroller.
- Observera att NetBIOS-namnet bara är en del av ett fullständigt kvalificerat domännamn – till exempel är sales.mittföretag.com ett fullständigt kvalificerat domännamn och SALES är domänens NetBIOS-namn.) Värdet för inställningen är ett DNS-namn, ett fullständigt kvalificerat domännamn eller en IP-adress för domänkontrollanten för respektive domän.
Notera:
Det kan också finnas flera domänkontroller. I ett sådant fall konfigureras den första domänkontrollern som auth.ntlm.DOMAIN.domaincontroller och de efterföljande domänkontrollerna som: auth.ntlm.DOMAIN.domaincontroller.1 , auth.ntlm.DOMAIN.domaincontroller.2 och så vidare.
- Observera att NetBIOS-namnet bara är en del av ett fullständigt kvalificerat domännamn – till exempel är sales.mittföretag.com ett fullständigt kvalificerat domännamn och SALES är domänens NetBIOS-namn.) Värdet för inställningen är ett DNS-namn, ett fullständigt kvalificerat domännamn eller en IP-adress för domänkontrollanten för respektive domän.
Endast för NTLMv1: Observera att inställningen auth.ntlm.defaultdomaincontroller också bör konfigureras (den finns under inställningarna för den inkopplade autentiseringsenheten i plattformsinställningarna). Inställningens värde är ett DNS-namn, ett fullständigt kvalificerat domännamn eller en IP-adress för domänkontrollanten. Denna inställning används om webbläsaren inte skickar information om domänen eller om domänen inte är känd. Det problematiska fallet är när en IE-användare kommer från en okänd domän. Om standarddomänkontrollanten inte är konfigurerad tror IE att NTLM-förhandlingen inte är klar och skickar inte användarnamnet och lösenordet från inloggningsformuläret till ESM-servern. Det vill säga, autentiseringen kommer alltid att misslyckas.
Webbläsarstöd för NTLM HTTP-autentisering
Microsoft Internet Explorer förhandlar om NTLM HTTP-autentisering transparent. När IE har förhandlat om NTLM HTTP-autentisering kommer den proaktivt att omförhandla NTLM för POST-förfrågningar för allt innehåll som är kopplat till servern. Det betyder att IE kommer att omförhandla varje gång den behöver skicka POST-data till ESM (t.ex. spara datakort). Det är möjligt att ändra IE:s beteende men det kräver redigering av Windows-registret.
För att NTLM-autentiseringen ska fungera som avsett måste IE:s säkerhetsinställningar konfigureras på följande sätt:
- ESM-URL:en måste konfigureras som en betrodd webbplats i IE (från Internetalternativ > Säkerhet > Betrodda webbplatser > Webbplatser > Avancerat ).
- Inloggningsalternativet i IE: s säkerhetsinställningar måste vara inställt på antingen " Automatisk inloggning endast i intranätzonen " eller " Automatisk inloggning med aktuellt användarnamn och lösenord " (från Internetalternativ > Säkerhet > Tillförlitliga webbplatser > Anpassad nivå… ).
Säkerhetsinställningar för Internet Explorer för NTLM-autentisering
Notera:
Automatiska inloggningar fungerar endast när ESM körs i ett lokalt nätverk och ESM-användare är inloggade direkt på Windows som körs på en domän som är betrodd av ESM (mer specifikt på samma domän där ESM utför NTLM-autentiseringen). Om ESM behöver nås från ett WAN bör NTLM-autentisering inte användas.
Mozilla och Mozilla-baserade webbläsare som Firefox stöder NTLM HTTP-autentisering, men kommer alltid att be användaren om inloggningsuppgifter. Det är dock möjligt att konfigurera Mozilla-baserade webbläsare för att utföra NTLM-förhandling transparent:
- Starta webbläsaren.
- Skriv about:config till adressfältet.
- Redigera inställningen network.automatic-ntlm-auth.trusted-uris: Värdet för denna inställning är en kommaseparerad lista med URL-prefix eller domäner. Lägg till URL-prefixet för din ESM-server, till exempel http://efecteserver .
Denna ändring kan också göras i en Mozilla-konfigurationsfil för enklare distribution.
Notera:
NTLM HTTP-autentisering bör endast användas med servrar i en intranätzon, eftersom NTLM-lösenordshash lätt kan knäckas med brute-force-dictionary-attacker. Om NTLM används över osäkra nätverksanslutningar kan säker kommunikation uppnås med SSL (HTTPS).
NTLM-autentisering kommer förmodligen att misslyckas om det finns en brandvägg mellan ESM-servern och domänkontrollanten. Brandväggar blockerar vanligtvis SMB-meddelanden.
Konfigurera Kerberos-autentisering (endast lokalt)
För bredast möjliga klientstöd och bästa säkerhet kan Kerberos-autentisering användas. Nackdelen med Kerberos är att även om det är det säkraste autentiseringsalternativet, är det också det svåraste att få att fungera korrekt. För de flesta fall där det bara finns Windows-arbetsstationer borde NTLMv2 vara mer än tillräckligt och är mycket lättare att få att fungera.
Med inställningen auth.sso.use.fully.qualified.account.name kan ESM konfigureras att jämföra Windows-användarnamn med ESM-användarnamn med hjälp av fullständigt kvalificerat kontonamn (DOMAIN\användarnamn). Denna konfiguration fungerar med alla SSO-autentiseringar: NTLMv1, NTLMv2 och Kerberos. Detta kräver att ESM-användare har sina användar-ID:n i formatet DOMAIN\användarnamn.
Så här konfigurerar du Kerberos-autentisering i ESM
- Användare måste ha samma användarnamn i Windows-domänen och ESM.
- Negotiate måste konfigureras som en av autentiseringsmetoderna. Detta kan göras genom att lägga till värdet negotiate till inställningen auth.chain (från Underhåll > Redigera inställningar) – till exempel auth.chain = negotiate , database. Denna exempelkonfiguration aktiverar Kerberos-förhandlingsautentisering för ESM och gör det till den första autentiseringsmetoden som kommer att provas.
- Ändra värdet för plattformsinställningen negotiate.protocol till Negotiate. Observera att ändringar av den här inställningen inte träder i kraft förrän ESM-tjänsten har startats om.
Om du vill köra ESM-tjänsten med någon annan användare än det lokala systemet måste du inaktivera behovet av Kerberos-förautentisering för den användaren i Active Directory och skapa ett Service Principal Name (SPN) för den som matchar servern där ESM körs. Här är ett exempel på SPN: HTTP/efecteserver.domain.com.
Webbläsarkonfigurationen för Kerberos-autentisering är densamma som för NTLM i Internet Explorer. I Firefox är inställningen där ESM-servern behöver läggas till network.negotiate-auth.trusted-uris.
LDAP-autentisering med flera domäner (endast lokalt)
Autentisering från flera domäner kan aktiveras genom att sätta värdet för plattformsinställningen auth.ldap.multidomain.enabled till true.
LDAP-webbadresser måste anges med inställningarna auth.ldap.host.uri.DOMAIN där ordet DOMAIN måste ersättas med domänens faktiska namn. Denna inställning kan ha flera värden separerade med kommatecken. Exempel: auth.ldap.host.uri.SALES= ldap://dc1:3268,ldap://dc2:3268
Alla domänkontrollanter som används här måste ha Global Catalog (GC) aktiverad (standardporten för den är 3268). GC behövs eftersom vi inte har några grundläggande DN definierade för domänerna och endast GC tillåter sökningar utan den. Användare som loggar in i ESM måste ange sitt användarnamn i formatet DOMÄN\användarnamn.
Servlet-autentisering
Servlet-autentisering kan konfigureras via specifika plattformsinställningar, vilket möjliggör inloggningskontroll baserat på Active Directory grupper och automatiskt skapande av användarkonton i ESM baserat på servlet-autentisering.
- servlet.auth.admin.ad.group – Namn på den AD -grupp som tillåter administratörer att logga in på ESM. Flera grupper stöds. Värdena ska separeras med kommatecken.
- servlet.auth.create.users – Om användarkontot inte redan finns kommer det att skapas. Standardvärde sant.
- servlet.auth.person.groups.attribute.code - Gruppattributkod på "personmall" som innehåller en referens till mallen " Active Directory Group".
- servlet.auth.person.template.code - Mallkod som innehåller personlig information.
- uid - Gruppera attributkod på "personmall" som innehåller en sträng för användar-ID i Active Directory .
- servlet.auth.person.user.attribute.code - Gruppera attributkod på "personmall" som innehåller en referens till Efecte-användarmallen.
- servlet.auth.user.ad.group - Namn på AD -gruppen som tillåter vanliga användare att logga in på ESM. Flera grupper stöds. Värdena ska separeras med kommatecken.
- servlet.auth.user.folder.code - Mappkod för en mapp i behörighetsträdet där en ny användare kommer att skapas.
- servlet.auth.user.name.attribute.code - Gruppera attributkod på "Användare"-mallen som innehåller en sträng för användarnamnet.
- servlet.auth.user.person.attribute.code - Gruppera attributkod på "Användare"-mallen som innehåller en referens till Person-mallen.
- servlet.auth.user.readonly.roles - Administratörsrollnamn som ges till användare som känns igen som skrivskyddade användare.
- De tillhör inte "servlet.auth.user.ad.group" eller "servlet.auth.admin.ad.group".
- Om den här inställningen är tom kan användare som inte tillhör någon av dessa roller inte logga in.
- De tillhör inte "servlet.auth.user.ad.group" eller "servlet.auth.admin.ad.group".
- servlet.auth.user.roles - Administratörsrollnamn som ges till användare som identifieras som vanliga användare. Se "servlet.auth.user.ad.group".