Dela via

Viktig information

  • Artikel

Uppdaterad: 19 juni 2015

Gäller för: Azure

Det här avsnittet beskriver de nya funktionerna i varje version av Microsoft Azure Active Directory Access Control (kallas även Access Control Service eller ACS), förklarar hur varje version av produkten skiljer sig från dess föregångare och markerar eventuella icke-bakåtkompatibla ändringar som kan påverka kod som skrivits för en tidigare version.

  • Mars 2015 – Migrera ACS-namnområden till Google OpenID Anslut

  • Juni 2014 – Stöd för GoogleS identitetsprovider

  • Viktig information om uppdateringen från juli 2013

  • Viktig information om uppdateringen december 2012

  • Viktig information om uppdateringen september 2012

  • Viktig information om uppdateringen juni 2012

  • Viktig information om uppdateringen maj 2012

  • Viktig information om uppdateringen januari 2012

  • Viktig information om uppdateringen för juli 2011

Mars 2015 – Migrera ACS-namnområden till Google OpenID Anslut

ACS har implementerat en funktion som hjälper ACS-namnområdesägare att migrera sina Konfigurationer för Google-identitetsprovider från OpenID 2.0 till OpenID Anslut. Kunderna har fram till den 1 juni 2015 på sig att migrera sina ACS-namnområden till OpenID-Anslut och fram till den 1 januari 2017 för att migrera sin serverdelskod för att använda OpenID-Anslut identifierare. Om du inte utför lämplig åtgärd före varje tidsgräns kommer det att orsaka avbrott i dina program. Detaljerad vägledning finns i Migrera ACS-namnområden till Google OpenID Anslut.

Juni 2014 – Stöd för GoogleS identitetsprovider

Från och med den 19 maj 2014 kan nya ACS-namnområden inte använda Google som identitetsprovider. ACS-namnrymder som använde Google och registrerades före den 19 maj 2014 påverkas inte. Den här nya begränsningen finns eftersom Google avvecklar stödet för OpenID 2.0, som ACS är beroende av, och har stängt registreringen för nya program. Befintliga ACS-namnrymder som använde Google fortsätter att fungera fram till den 20 april 2015. Om ditt program kräver stöd för Google-konton rekommenderar vi att du registrerar ditt program med dem direkt.

Om en användare försöker logga in på ett nytt ACS-namnområde med sitt Google-konto omdirigeras de till en HTTP 400-felsida.

New ACS namespace and Google error

Viktig information om uppdateringen från juli 2013

För att öka tillgängligheten och prestandan för ACS för alla användare har ACS implementerat en gräns på 30 tokenbegäranden per sekund för varje namnområde. Om ett namnområde överskrider den här gränsen under en längre period avvisar ACS tokenbegäranden från namnområdet under intervallets varaktighet och returnerar felet HTTP 429/ACS90055 "För många begäranden". Mer information finns i BEGRÄNSNINGAR för ACS-tjänsten och ACS-felkoder.

Viktig information om uppdateringen december 2012

Nya funktioner

Uppdateringen av ACS i december 2012 innehåller följande nya funktioner:

Stöd för federerad enkel utloggning med hjälp av protokollet WS-Federation

Webbprogram som använder ACS för att aktivera enkel inloggning (SSO) med identitetsprovidrar som använder WS-Federation protokollet kan nu dra nytta av funktioner för enkel utloggning. När en användare loggar ut från ett webbprogram kan ACS automatiskt logga ut användaren från identitetsprovidern och från andra förlitande part-program som använder samma identitetsprovider.

Den här funktionen är aktiverad för WS-Federation identitetsprovidrar, inklusive Active Directory Federation Services (AD FS) 2.0 och Windows Live ID (Microsoft-konto). För att aktivera enkel utloggning utför ACS följande uppgifter för WS-Federation protokollslutpunkter:

  • ACS identifierar wsignoutcleanup1.0-meddelanden från identitetsprovidrar och svarar genom att skicka wsignoutcleanup1.0-meddelanden till program från förlitande part.

  • ACS identifierar wsignout1.0 och wreply-meddelanden från förlitande part-program och svarar genom att skicka wsignout1.0-meddelanden till identitetsprovidrar och wsignoutcleanup1.0-meddelanden till förlitande part-program.

Mer information finns i Kodexempel: ASP.NET MVC 4 med federerad utloggning och passiv autentisering för ASP.NET i WIF.

Avbryta supporten för ACS 1.0

Support för Access Control Service 1.0 upphör i den här versionen, inklusive stöd för migrering från Access Control Service 1.0 till Access Control Service 2.0.

Navigera till Access Control namnområden i den nya Azure-hanteringsportalen

Den nya Azure-hanteringsportalen (https://manage.WindowsAzure.com) innehåller en väg till den välbekanta ACS-hanteringsportalen där du skapar och hanterar Access Control namnområden.

Så här navigerar du till ACS-hanteringsportalen:

  1. Gå till Microsoft Azure Management Portal (https://manage.WindowsAzure.com), logga in och klicka sedan på Active Directory. (Felsökningstips: "Active Directory"-objektet saknas eller är inte tillgängligt)

  2. Klicka på ett Access Control namnområde och klicka sedan på Hantera.

Om du vill skapa en Access Control namnrymd klickar du på Ny, klickar på App Services, klickar på Access Control och sedan på Snabbregistrering. (Eller klicka på Access Control namnområden innan du klickar på Ny.)

Om du vill ha hjälp med ACS-hanteringsuppgifter i Microsoft Azure-hanteringsportalen klickar du på Active Directory och sedan på Hjälp (?). (Eller klicka på Active Directory, klicka på Access Control namnområden och klicka sedan på Hjälp.)

Navigera till Access Control namnrymd för en Service Bus

När du skapar ett Service Bus namnområde i skapar portalen automatiskt ett Access Control namnområde för Service Bus.

Så här konfigurerar och hanterar du Access Control namnrymd för en Service Bus:

  1. Logga in på Azure-hanteringsportalen.

  2. Klicka på Service Bus och välj sedan en Service Bus.

  3. Klicka på Åtkomstnyckel och sedan på Öppna ACS-hanteringsportalen.

Om du vill kontrollera att Access Control-namnområdet är associerat med Service Bus kan du läsa fältet Tjänstnamnområde överst på sidan Access Control Service. Namnområdets namn består av Service Bus-namnet med suffixet "-sb".

Mer information finns i How to: Manage the Access Control Namespace for a Service Bus (Så här gör du: Hantera Access Control-namnområdet för en Service Bus).

Förbättringar i ACS-hanteringsportalen för att visa WS-Federation identitetsprovidernycklar, dölja lösenord

Den här versionen innehåller ett par förbättringar som rör visning och arbete med certifikat, nycklar och lösenord i ACS 2.0-hanteringsportalen:

  • Signeringscertifikat visas nu i avsnittet Redigera WS-Federation identitetsprovider – Tidigare var certifikat som importerats från WS-Federation metadata som användes för att verifiera signaturen för token som utfärdats från identitetsprovidern inte synliga i ACS-hanteringsportalen. I avsnittet Redigera WS-Federation identitetsprovider visas nu information om importerade certifikat, inklusive deras förfallodatum och status. Dessa certifikat kan nu uppdateras med en ny kryssruta om att importera data från WS-Federation metadata-URL vid sparande.

  • Lösenord och symmetriska signeringsnycklar är nu dolda som standard – För att förhindra oavsiktligt avslöjande av lösenord och symmetriska nycklar döljs dessa värden som standard på redigera-skärmarna i portalen. Om du avsiktligt vill visa värdet för ett lösenord eller en symmetrisk nyckel (till exempel så att det kan kopieras till ett program) måste du trycka på knappen "Visa lösenord" eller "Visa nyckel".

Möjlighet att federera katalogklienter med Access Control namnområden

Azure Active Directory klientorganisationer kan nu användas som identitetsprovidrar i Access Control namnrymder. Detta möjliggör många scenarier, till exempel att göra det möjligt för webbappen att acceptera både organisationsidentiteter från katalogklienter och konsumentidentiteter från sociala leverantörer som Facebook, Google, Yahoo!, Microsoft-konton eller någon annan OpenID-provider. Du hittar detaljerade instruktioner om hur du implementerar scenariot i det här inlägget, Etablera en Azure Active Directory klientorganisation som en identitetsprovider i ett ACS-namnområde.

SAML 2.0-protokollstöd för förlitande part-program (förhandsversion av utvecklare)

ACS stöder nu SAML 2.0-protokollet för utfärdande av token till program från förlitande part. SAML 2.0-protokollstöd har släppts som en förhandsversion av utvecklare, vilket innebär att information om SAML 2.0-protokollimplementeringen fortfarande kan komma att ändras. Mer information finns iFörhandsversion av utvecklare: SAMLProtocol.

Kända problem

I uppdateringen från december 2012 Microsoft Azure Active Directory Access Control (även kallat Access Control Service eller ACS) har följande kända problem identifierats:

Azure Co-Administrators kan nu hantera Access Control namnområden. En åtgärd krävs dock för att sprida befintliga medadministratörer till en befintlig Access Control namnrymder.

Före uppdateringen från november 2012 löste vi ett problem där endast den primära Azure-tjänstadministratören som standard kunde hantera Access Control namnrymder som skapats i prenumerationen. Om en Azure-medadministratör försökte komma åt ACS-hanteringsportalen för ett Access Control namnområde skulle de få någon av följande ACS-felkoder:

  • ACS50000: Ett fel uppstod när en token utfärdades.

  • ACS60000: Ett fel uppstod vid bearbetning av regler för förlitande part med utfärdaren "uri:WindowsLiveID"

  • ACS60001: Inga utdataanspråk genererades under regelbearbetningen.

Det här problemet har nu lösts för nya Access Control namnrymder som skapats av en Azure-tjänstadministratör eller medadministratör. Kunder med namnrymder som fanns före korrigeringen måste dock utföra följande lösning för att medadministratörsdata ska spridas till dessa namnområden:

  1. Logga in på Azure Portal (https://windows.azure.com/) med autentiseringsuppgifter för tjänstadministratör eller kontoadministratör.

  2. Ta bort och lägg till medadministratören igen med hjälp av vägledningen i How to Add and Remove Co-Administrators for Your Azure Subscriptions (https://msdn.microsoft.com/library/windowsazure/gg456328.aspx) ()

  3. Logga ut och logga in på Azure Portal med autentiseringsuppgifterna som medadministratör. Sedan kan du hantera Access Control namnrymder.

Viktig information om uppdateringen september 2012

I september 2012 mottog Microsoft Azure Active Directory Access Control (även kallat Access Control Service eller ACS) en uppdatering som innehöll följande ändringar:

EntityID som publiceras i WS-Federation metadata som genereras av ACS har nu konsekvent gemener

Attributet "entityID" i WS-Federation metadata som publiceras av Access Control namnområden är nu alltid gemener. I tidigare versioner använde den bokstavsfallet som angavs när namnområdet skapades i Azure Portal. Attributet "entityID" identifierar Access Control namnrymd för förlitande part-program och nedan är ett exempel på attributet:

<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://lowercase-namespace.accesscontrol.windows.net/" ID="_e4a0006c-c23c-41c0-8f87-baa110afaf1d">

Den här ändringen krävdes för att åtgärda potentiella tokenverifieringsproblem där bokstavsfallet för Access Control-namnområdet i den ACS-utfärdade token (vilket alltid är gemener) inte matchar bokstavsfallet för Access Control namnområdet som importerats av den förlitande parten. Förlitande parter som använder Windows Identity Foundation påverkas inte av problem med skiftlägeskänslighet.

X.509-certifikat som laddats upp till ACS har nu en storleksbegränsning för offentliga nycklar på 4 096 bitar

Alla X.509-certifikat som laddats upp till ett Access Control namnområde via ACS-hanteringsportalen eller hanteringstjänsten måste nu ha en offentlig nyckelstorlek som inte är större än 4 096 bitar. Detta inkluderar certifikat som används för tokensignering, tokenkryptering och tokendekryptering.

I Windows kan du kontrollera storleken på en offentlig nyckel för ett certifikat genom att öppna certifikatet (. CER-fil, väljer fliken "Information" och kontrollerar värdet för fältet "Offentlig nyckel". Certifikat som använder algoritmen för säker sha256RSA-signatur har en offentlig nyckel på 2 048 bitar.

Alla befintliga certifikat som har en nyckelstorlek som är större än 4 096 bitar fortsätter att fungera med ACS, men dessa certifikat kan inte sparas om i ACS förrän de ersätts med ett kompatibelt certifikat.

Mindre ändring av markeringsalgoritmen för "primär nyckel" som används när ACS signerar en token med ett X.509-certifikat

I ACS-hanteringsportalen och hanteringstjänsten finns fältet "Gör primär" för certifikat för tokensignering som, när det väljs, gör att ACS signerar token med det certifikatet. Med den här versionen, om inga konfigurerade tokensigneringscertifikat har fältet "Gör primär" markerat, använder Access Control-namnområdet det befintliga icke-primära tokensigneringscertifikatet som har det tidigaste giltiga startdatumet för att signera token. ACS signerar fortfarande inte token med ett icke-primärt tokensigneringscertifikat om det finns ett primärt certifikat, men är ogiltigt eller har upphört att gälla.

JWT Beta: Ändra signeringsbeteendet när du använder ett globalt namnområdescertifikat eller en nyckel för att signera en JWT-token

När betastöd för JSON Web Token-formatet (JWT) släpptes i juni 2012 använde ACS följande prioritetsordning för att avgöra vilken nyckel som ska användas för att signera varje JWT-token som utfärdas till varje förlitande part-program:

  • Symmetrisk signeringsnyckel tilldelad till förlitande part, om tillgänglig

  • X.509-signeringscertifikat tilldelat till förlitande part, om tillgängligt

  • Symmetrisk signeringsnyckel tilldelad till Access Control-namnområdet

  • X.509-signeringscertifikat som tilldelats till Access Control-namnområdet

Från och med den här versionen stöds inte längre symmetriska nycklar för namnområdesomfattande för signering av JWT-token. Nedan visas den nya prioritetsordningen för signering av JWT-token:

  • Symmetrisk signeringsnyckel tilldelad till förlitande part, om tillgänglig

  • X.509-signeringscertifikat tilldelat till förlitande part, om tillgängligt

  • X.509-signeringscertifikat som tilldelats till Access Control-namnområdet

Viktig information om uppdateringen juni 2012

I juni 2012 mottog ACS en uppdatering som innehöll följande nya funktion:

JWT-format är nu tillgängligt för förlitande part-program (Beta)

Den här uppdateringen introducerar stöd för JSON Web Token (JWT) BETA-format i ACS. JWT är ett enkelt, JSON-kodat tokenformat som kan signeras med ett X.509-certifikat eller en symmetrisk nyckel och som kan utfärdas av ACS till förlitande partsprogram via något av följande protokoll:

  • OAuth 2.0

  • WS-Federation

  • WS-Trust

JWT-tokenformatet är nu ett valbart alternativ i avsnittet Förlitande part-program i ACS-hanteringsportalen och kan även konfigureras via ACS-hanteringstjänsten.

Mer information om JWT-tokenformatet finns i JSON Web Token-specifikationen. ACS-kodexempel som innehåller JWT-token kommer vid ett framtida datum.

Viktigt

JWT-stöd markeras som "Beta" i ACS, vilket innebär att all information om JWT-implementeringen kan komma att ändras. Utvecklare uppmuntras att experimentera med det här tokenformatet. JWT bör dock inte användas i produktionstjänster, eftersom beteendet kan ändras utan föregående meddelande.

Viktig information om uppdateringen maj 2012

I början av maj 2012 fick ACS en uppdatering som innehöll följande ändring:

Ändringar av entitets-ID-egenskaper som exponeras via hanteringstjänsten

ACS-hanteringstjänsten exponerar för närvarande en ID-egenskap för var och en av de entitetstyper som den stöder, enligt beskrivningen i REFERENS FÖR ACS Management Service API. Dessa ID-egenskaper anges och hanteras automatiskt av ACS.

I den här tjänstuppdateringen migreras ACS till ett annat databasschema och därför ändras de ID:n som exponeras via hanteringstjänsten för alla entitetstyper.

Det är ovanligt och rekommenderas vanligtvis inte att program lagrar eller använder ett hårdkodat beroende av dessa ID:er för att köra frågor mot specifika entiteter via hanteringstjänsten. I stället rekommenderar vi att entitetstyperna RelyingParty, ServiceIdentity, RuleGroup och Issuer efterfrågas med hjälp av egenskapen Namn och att andra entitetstyper efterfrågas med ett överordnat entitets-ID (t.ex. RuleGroupId när det gäller regler eller IssuerId för identitetsprovidrar).

Ändringar i databassortering för regelbearbetning

För att utöka stödet för internationella språk och förbättra säkerheten uppdaterar den här versionen av ACS den underliggande SQL databassortering som används för att jämföra inkommande anspråk från SQL_Latin1_General_CP1_CI_AS till Latin1_General_100_BIN2. Den här ändringen gör att ACS kan stödja ytterligare teckenuppsättningar och kombinationer av teckenuppsättningar. Program som förlitar sig på inkommande anspråk som innehåller strängar med flera teckenuppsättningar, som inte stöds av SQL_Latin1_General_CP1_CI_AS kan se olika eller ytterligare anspråk till följd av den nya sorteringen. Kunder som vill dra nytta av den här nya funktionen uppmuntras att validera sina program för kompatibilitet med den nya SQL sortering.

Viktig information om uppdateringen januari 2012

Den 25 januari 2012 mottog ACS 2.0 en uppdatering som innehöll följande ändringar:

  • Ändring i ACS-felsvar för misslyckade autentiseringsbegäranden

  • Ändring i OAuth 2.0-felkoder för misslyckade autentiseringsbegäranden

Ändring i ACS-felsvar för misslyckade autentiseringsbegäranden

I den tidigare versionen svarade ACS med olika felkoder när en klient autentiserades med en obefintlig utfärdare (felkod: ACS50026) eller felaktiga autentiseringsuppgifter (felkod: ACS50006). Dessa felkoder har tidigare genererats när en klient försökte autentisera med ett ogiltigt tjänstidentitetsnamn eller med hjälp av en SWT- eller SAML-token som utfärdats från en ogiltig identitetsprovider.

ACS returnerar felkoderna ACS50008, ACS50009 eller ACS50012 för en misslyckad autentisering i fall av SWT, SAML respektive användarnamn/lösenord. Mer information finns i tabellen nedan:

Autentiseringssvar Före Efter

Obefintlig utfärdare

ACS50026 IssuerNotFound

ACS50008 InvalidSwt,

ACS50009 InvalidSaml, OR

ACS50012 AuthenticationFailed

Felaktiga autentiseringsuppgifter

ACS50006 InvalidSignature

Ändring i OAuth 2.0-felkoder för misslyckade autentiseringsbegäranden

Även i den tidigare versionen svarade ACS med olika OAuth 2.0-felkoder när en klient autentiserades med en icke-existerande utfärdare (invalid_client) eller felaktiga autentiseringsuppgifter (invalid_grant). Det här beteendet har också uppdaterats och ACS returnerar invalid_request när OAuth 2.0-begäran är felaktig, invalid_client om klienten misslyckas med autentiseringen eller om försäkran som tillhandahålls för autentisering är felaktig eller ogiltig och invalid_grant om auktoriseringskoden är felaktig eller ogiltig. Mer information finns i tabellen nedan:

Autentiseringssvar Exempel Före Efter

Obefintlig utfärdare

invalid_client

invalid_client

Felaktiga autentiseringsuppgifter

SWT har signerats med en felaktig nyckel. Klient-ID och autentiseringsuppgifter matchar de som konfigurerats i ACS.

invalid_grant

Autentiseringen misslyckades

Verifieringen av målgrupps-URI misslyckades. Certifikatverifieringen misslyckades. Försäkran från en tjänstidentitet innehåller själv utfärdade anspråk.

invalid_grant

Felaktig försäkran

Signaturen saknas i SWT. SAML-försäkran är inte giltig XML.

invalid_request

Felaktig auktoriseringskod

invalid_grant

invalid_grant

Auktoriseringskoden är ogiltig

invalid_grant

Felaktig OAuth2-begäran

invalid_request

invalid_request

Viktig information om uppdateringen för juli 2011

Viktig information för uppdateringen från juli 2011 av ACS 2.0 innehåller följande:

  • Förutsättningar

  • Nya funktioner

  • Ändringar

  • Kända problem

  • Kända problem

Förutsättningar

Alla Access Control-namnområden får automatiskt uppdateringen från juli 2011. Den här uppdateringen innehåller inga ändringar i ACS-kraven för nya eller befintliga kunder. Mer information om aktuella ACS-krav finns i KRAV FÖR ACS.

Nya funktioner

Uppdateringen från juli 2011 av ACS innehåller följande nya funktioner:

1. Reglerna stöder nu upp till två inkommande anspråk

ACS-regelmotorn stöder nu en ny typ av regel som tillåter att upp till två inkommande anspråk konfigureras, i stället för bara ett inkommande anspråk. Regler med två inkommande anspråk kan användas för att minska det totala antalet regler som krävs för att utföra komplexa funktioner för användarauktorisering.

I ACS-hanteringsportalen kan ett andra inkommande anspråk anges i en ny regel genom att klicka på Lägg till ett andra inkommande anspråk i regelredigeraren. I hanteringstjänsten kan regler med två inkommande anspråk konfigureras med entitetstypen ConditionalRule . Regler med ett inkommande anspråk konfigureras fortfarande med entitetstypen Regel för bakåtkompatibilitet.

Mer information om regler med två inkommande anspråk finns i Regelgrupper och Regler.

2. Lokalisering på elva språk

ACS-hanteringsportalen och den ACS-värdbaserade inloggningssidan för förlitande part-program stöder nu lokalisering på elva skrivna språk, inklusive engelska, franska, tyska, italienska, japanska, koreanska, ryska, spanska, portugisiska (Brasilien), förenklad kinesiska och traditionell kinesiska. Ett alternativ för "Engelska (internationell)" är också tillgängligt som använder ett alternativt datumformat för att ange och visa gällande/förfallodatum för nycklar. Det skrivna språket som visas för dessa användargränssnitt kan ändras på något av följande tre sätt:

  • Språkväljare – I ACS-hanteringsportalen kan det språk som visas omedelbart ändras med hjälp av en ny språkväljarmeny som visas i det övre högra hörnet i portalen.

  • URL – Det språk som visas i ACS-hanteringsportalen kan ändras genom att lägga till en "lang"-parameter i slutet av begärande-URL:en. De juridiska värdena för den här parametern är ISO 639-1/3166-språkkoder som motsvarar ett språk som stöds. Exempelvärden är en, de, es, fr, it, ja, ko, ru, pt-br, zh-cn och zh-tw. Nedan visas ett exempel på en URL för ACS-hanteringsportalen med en parameter som anger det språk som visas till franska:

    https://your-namespace.accesscontrol.windows.net/?lang=fr

  • Webbläsarinställningar – Om url-parametern "lang" eller språkväljaren aldrig har använts för att ange en språkinställning, kommer ACS-hanteringsportalen och ACS-värdbaserade inloggningssidor att fastställa standardspråket som ska visas baserat på de språkinställningar som anges i webbläsarinställningarna.

Ändringar

Följande är viktiga ändringar av tjänstbeteendet i den här versionen:

1. Kodning är nu UTF-8 för alla OAuth 2.0-svar

I den första versionen av ACS var teckenkodningsuppsättningen för alla HTTP-svar från OAuth 2.0-slutpunkten US-ASCII. I uppdateringen från juli 2011 är teckenkodningen för alla HTTP-svar nu inställd på UTF-8 för att stödja utökade teckenuppsättningar.

Kända problem

Följande är ett känt problem i den här versionen:

Regelredigeraren kan inte visa anpassade utfärdare som inte är associerade med identitetsprovidrar

För närvarande kan regelredigeraren i ACS-hanteringsportalen endast visa anspråksutfärdare som är associerade med en identitetsprovider eller ACS. Om en regel läses in som refererar till en utfärdare som inte motsvarar någon av dessa saker visas följande fel:

  • ACS80001: Den här regeln är konfigurerad för att använda en typ av anspråksutfärdare som inte stöds av hanteringsportalen. Använd hanteringstjänsten för att visa och redigera den här regeln.

Det finns två scenarier som stöds där en utfärdare kan finnas utan en associerad identitetsprovider i ACS:

  • I ett OAuth 2.0-delegeringsscenario skapas en utfärdarpost i Access Control namnrymd med hjälp av ACS-hanteringstjänsten och den här utfärdaren har ingen associerad identitetsprovider.

  • När en utfärdare skapas för att göra anspråk i en tokenbegäran över OAuth WRAP-protokollet, samtidigt som en identiskt namngiven tjänstidentitet används för att autentisera med ACS.

Kvoter

Från och med den här versionen har ACS inga begränsningar för antalet identitetsprovidrar, program från förlitande part, regelgrupper, regler, tjänstidentiteter, anspråkstyper, delegeringsposter, utfärdare, nycklar och adresser som kan skapas för en viss Access Control namnrymd.

Tjänstbegränsningar

Mer information om tjänstbegränsningar finns i Begränsningar för ACS-tjänsten.