
CA Optics - Analisador de Lacunas do Acesso Condicional do Azure AD
Projeto arquivado devido a mudanças nas prioridades de desenvolvimento e ao redirecionamento dos meus esforços na comunidade para outras áreas (PoCs, outras ferramentas e demonstrações/apresentações); o projeto está definido como somente leitura.
O Analisador de Lacunas do Acesso Condicional do Azure AD é uma solução para verificar lacunas que possam existir em configurações complexas de políticas de Acesso Condicional do Azure Active Directory.
Se você é novo no Acesso Condicional, recomendamos que revise o seguinte artigo da Microsoft: https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/overview
Comando de uma linha para executar esta ferramenta: (se esta é a única parte que você planeja ler e já concluiu a instalação)
node ./ca/main.js --mapping --skipObjectId=259fcf40-ff7c-4625-9b78-cd11793f161f --clearPolicyCache --clearTokenCache --clearMappingCache
Depois de concluir os pré-requisitos e ler este arquivo readme, considere o seguinte:
políticas reportOnly não são consideradas terminais:
Leia: scope
execute cada verificação com --clearPolicyCache
execute cada verificação com --clearMappingCache se você fizer alterações nos grupos/usuários relacionados às políticas
apenas políticas que visam usuários e aplicativos estão no escopo (este é o escopo mais comum, mas significa, por exemplo, que a política de registro de segurança não é avaliada)
Leia: scope
Comece com um ambiente de teste para adquirir experiência e definir expectativas sobre o funcionamento da ferramenta
se você tiver grupos ou usuários conhecidos que são excluídos das políticas, defina com --skipObjectIds os objetos a serem excluídos da verificação, a menos que queira confirmar as exclusões
Se você estiver executando verificações em vários ambientes, certifique-se de que logins e caches sejam removidos antes de executar novas verificações
Leia:parâmetros
az account clear e faça um novo login no ambiente que você planeja verificar com az loginRelease notes: 0.7.1
- Updated depedencies and report text outputs
Release notes: 0.7
- Uses beta endpoint now by default, --expand option now expands the results to report regardless of the use of --allTerminations
Release notes: 0.6.9
- using --expand=9c06d103-f5b0-4404-bb25-aec4636912cd,47087cd3-64e9-470b-980a-5662f498e016 and expand 10 group members to for separate inspection.
Release notes: 0.6.8
- When you update policy with any guest conditions in GUI that policy will be only available from the beta endpoint after the update (during preview).
- This update brings normalization for policies that are transfered to beta endpoint due to this behavior.
- The policy will be evaluated like the previous guest conditions, as long as the following conditions are included "internalGuest,b2bCollaborationGuest,b2bCollaborationMember" and no tenants are excluded from the policy. In order to evaluate transferred policies,
- use '--allowPreviewPolicies' when running CaOptics to account for this behavior
Release notes: 0.6.6-7 beta
- Allow use of different login endpoints for login and graph with params: --altLogin --altGraph
- Allow use of custom filtering for policies (this only recommended, when the policies do not adhere to expected schema)
Release notes: 0.6.5 beta
- Added counter to reporting when high number of permutations is also added to report (default is to add only unterminated)
- Minor code fixes changing <var> to <let>
- Report filename now includes day, month, year and tenantId e.g. report_day_4_month_9_year_2022-tenant_48f55450-183a-45d6-a9ce-68f3cbc68947.csv
Release notes: 0.6.4 beta
- Get more groups per single call (less batching)
- Fix race condition detected when generally using for await loops
- Enclose values with "" between delimitters (CSV)
Release notes: 0.6.3 beta
- Optimizations to way the mapped objects are handled.
- Mapped objects are cached. You can recreate the object mapping by using parama 'clearMappingCache'
- Lookup keys will start from 'user/group/role' conditions always first
- Added possibility to populate usermap with random UUID's to test for performance impact (this just debug option, and not really something that would be in non-beta versions)
Release notes: 0.6.2 beta
- Separated cache params into separate functions -> (clearTokenCache and ClearPolicyCache)
- Added possibility of running pre-optimized algorithm on permutations with param --aggressive (High memory consumption, only here for A/B testing)
- merge completed.
Release notes: 0.6.1 beta
- Basic version of CSV reporting added
- Streamlined permutation generation to ensure essential permutations are generated, and some permutations are are terminated earlier on the lookups
Release notes: 0.6 beta (first non "silent" release)
- App displayNames added to MD report. Object type added to the user type
Release notes: 0.5.2,0.5.1,0.5 beta (see previous branches for release notes)

Exemplo de detecção entre políticas
❌ Qualquer permutação com valor 0 significa que nenhuma política foi encerrada para aquela combinação específica de condições.
| Política | Terminações | consulta |
|---|---|---|
| All | 0 | Applications:88cc92be-d474-4d95-a57d-7b3ef701f510 -> Locations:finland -> users:GuestsOrExternalUsers |
| All | 0 | Applications:88cc92be-d474-4d95-a57d-7b3ef701f510 -> Locations:finland -> users:Jane Doe |
| All | 0 | Applications:88cc92be-d474-4d95-a57d-7b3ef701f510 -> Locations:finland -> users:John Doe |
✅ Leia a descrição detalhada da detecção em docs/example.md
As permutações são geradas por getPol2.js
(Visualização por https://jsoncrack.com/)
Tempo de execução
Se você preferir não usar a versão 'dispare e esqueça'```bash nvm use 16 git clone https://github.com/jsa2/caOptics; cd caOptics; npm install;
**Configuração de execução do tipo dispare e esqueça para o Azure Cloud Shell (Bash)**```bash
curl -o- https://raw.githubusercontent.com/jsa2/caOptics/main/init.sh | bash;
# Force reload of NVM
export NVM_DIR="$([ -z "${XDG_CONFIG_HOME-}" ] && printf %s "${HOME}/.nvm" || printf %s "${XDG_CONFIG_HOME}/nvm")"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"
# This loads nvm
Please provide the Markdown content to translate.```bash cd caOptics
az login
**Relacionado ao Azure AD**
- Função Leitor de Segurança do Azure AD habilitada
- Se você tiver o Azure CLI e uma sessão CLI existente, esta ferramenta usará essa [sessão](https://github.com/jsa2/caoptics/blob/main/tokenHandler/getCode.js).
- Se você não tiver o Azure CLI instalado, apenas o clientID do Azure CLI é usado para obter tokens com o fluxo device_code iniciado pelo cliente http Node.js
>
**Os seguintes pacotes de código aberto são usados**
Para reduzir a quantidade de código, usamos as seguintes dependências para operação e estética (Parabéns aos mantenedores desses pacotes fantásticos. O link da licença de cada pacote é fornecido na coluna de licença)
pacote | estética | operação | licença
-|-|-|-
[axios](https://www.npmjs.com/package/axios)||✅ | [MIT](https://github.com/axios/axios/blob/v1.x/LICENSE)
[yargs](https://www.npmjs.com/package/yargs)||✅ | [MIT](https://github.com/yargs/yargs/blob/main/LICENSE)
[jsonwebtoken](https://www.npmjs.com/package/jsonwebtoken) | |✅|[MIT](https://github.com/auth0/node-jsonwebtoken/blob/master/LICENSE)
[chalk](https://www.npmjs.com/package/chalk)| ✅ | |[MIT](https://github.com/chalk/chalk/blob/main/license)
[js-beautify ](https://www.npmjs.com/package/js-beautify) | ✅ | |[MIT](https://github.com/beautify-web/js-beautify/blob/main/LICENSE)
**Qual acesso de rede é necessário para que isso funcione?**
1. Os seguintes hosts são necessários para a operação ```sh
graph.microsoft.com
login.microsoftonline.com
Se você planeja executar esta ferramenta em um ambiente com rede restrita, baixe as dependências primeiro em um ambiente que permita acesso a instalações de pacotes e ao github.com. Você pode então transferir todo o diretório de instalação compactado para o ambiente com rede restrita
Abaixo está o trace típico que faço quando estou executando pacotes de terceiros nos meus aplicativos Node.js. Ele mostra as URLs que são chamadas em tempo de execução

Leia a Licença
⚠️ Nenhuma sanitização de entrada é realizada nos parâmetros de inicialização, pois sempre se assume que a entrada desses parâmetros é controlada e que esta ferramenta não é executada em ambiente não controlado (ou sem supervisão). Embora eu não tenha revisado todos os caminhos, acredito que alcançar a execução de shellcode é trivial. Esta ferramenta não assume entrada hostil, portanto a recomendação é que você não cole argumentos de inicialização na linha de comando sem revisá-los antes.
Recomendamos que esta ferramenta seja sempre executada somente com permissões somente leitura (se você tiver o AZ CLI instalado, remova o cache do AZ CLI antes de prosseguir az account clear)
A autenticação legada não é avaliada quando a política avaliada inclui apenas condições de autenticação legada - Contexto: a Microsoft está em processo de descontinuação da autenticação básica para o Exchange, portanto grande parte da avaliação de autenticação legada logo (final de 2022) se tornará irrelevante.
Você ainda pode optar pelo parâmetro
--includeLegacyAuthpara incluir apenas políticas de autenticação legada na combinação. Tenha em mente que isso assumirá que o Legacy Auth está coberto para todos os aplicativos (avaliando-o também para aplicativos que não suportam autenticação legada), e não apenas para o EXO.
A ferramenta armazena o token de atualização (refresh token) do AZ CLI localmente para manter a persistência da sessão - Os tokens são armazenados em cache localmente em texto puro (assim como são armazenados em cache com o Azure CLI no BASH, independentemente de você usar esta ferramenta ou não). Embora o cache de tokens possa ser criptografado, ele não oferece nenhum benefício para o PoC neste momento. Criptografar o cache de tokens também não ajudaria muito, pois possivelmente muitas outras ferramentas/aplicativos em execução no sistema armazenam tokens de atualização opacos em formato de texto puro.
Em relação aos relatórios e permutações: ainda estou trabalhando para descobrir o melhor equilíbrio entre legibilidade e detalhamento. Acredito que todas as lacunas no escopo são capturadas, mas fiz inúmeras alterações no algoritmo dessas detecções e, portanto, ainda pode haver alguns casos extremos que não considerei.
Esta ferramenta resolve o problema de encontrar lacunas em políticas de Acesso Condicional, mesmo quando a lacuna não apareceria nos logs de entrada (sign-in).
Como esta ferramenta é diferente das ferramentas existentes?
| Ferramenta | BPA ¹ | Análise de lacunas | Requisitos adicionais |
|---|---|---|---|
Microsoft Azure AD Assessment | ✅ | - Apenas em relação ao BPA | novo registro de aplicativo |
Conditional access gap analyzer workbook | - | ² Somente quando a lacuna pode ser atribuída ao evento de entrada | os logs são exportados para o workspace do Log Analytics |
CA Optics | - | ✅ | ³ Acesso ao Azure Cloud Shell e permissões para ler políticas de CA via API do MS Graph |
adicionais
¹ Analisador de Melhores Práticas
² A lacuna não pode ser identificada se as condições que a expõem nunca foram registradas no log de entrada
³ O Cloud Shell não é um requisito estrito, mas é uma boa alternativa para usuários desta ferramenta que possam não ter o Node.js instalado
Na versão 0.5, as condições cobertas são as seguintes:
✅Users / Roles /Groups
✅Cloud apps (apenas políticas que definem todos os aplicativos, ou aplicativos individuais, estão no escopo)
✅Device platforms (ex.: user-agents)
✅Locations
✅Client Apps (ex.: aplicativos de navegador / desktop e móveis) ¹
✅Access Controls (Grant / Block) (Apenas políticas com Access Controls habilitados estão no escopo ²)
(Qualquer coisa que não esteja na lista não é avaliada. Ex.: políticas baseadas em risco não são consideradas como cobertura de lacunas, pois a detecção de risco não é considerada perfeita e deve ser usada antes em situações em que você quer bloquear algo, em vez de exigir MFA apenas quando há risco associado)
¹ Dado que a Microsoft está descontinuando o Legacy Auth, a autenticação legada não é revisada ² A aplicação da política precisa estar habilitada (políticas somente relatório não são avaliadas por padrão, mas podem ser incluídas com determinada flag)
É importante entender que a ferramenta reflete as opiniões de seus criadores no design de políticas:
Há duas escolas de design de Acesso Condicional
Baseado em inclusão: Aplicar CA apenas a condições que correspondam aos padrões de uso previstos da organização.
Baseado em exclusão: Aplicar CA em todas as condições e, em seguida, criar exclusões restritas para lidar com essas exceções.
⚠ Esta ferramenta só funciona para a última escola de design de CA. A base desse design é que o atacante considera todos os padrões de acesso válidos, até mesmo aqueles que a organização pode não considerar válidos para seu próprio uso. Se seus padrões de uso não se encaixam na abordagem adotada por esta ferramenta, recomendamos que você considere, em vez disso, o uso das ferramentas existentes
Essa linha de pensamento é semelhante à Melhor Prática da Microsoft 'Aplicar políticas de Acesso Condicional a todos os aplicativos' com a distinção, em relação à afirmação a seguir, de que, além de todos os aplicativos, também todas as outras condições configuradas devem ser cobertas por uma política, ou por determinado tipo de exclusão ¹
Garanta que todo aplicativo tenha pelo menos uma política de Acesso Condicional aplicada. Do ponto de vista da segurança, é melhor criar uma política que abranja todos os aplicativos na nuvem e, em seguida, excluir os aplicativos aos quais você não deseja que a política se aplique. Isso garante que você não precise atualizar as políticas de Acesso Condicional sempre que integrar um novo aplicativo.
¹ Esta ferramenta considera a lacuna coberta também quando é usada a exclusão por localização confiável ou dispositivo confiável, e a política não é aplicada devido ao uso de dispositivo ou localização confiável. Vale dizer que existem melhores práticas de uso administrativo que exigem que a localização confiável ou o dispositivo confiável sejam combinados com MFA.
O design atual exige que todas as condições sejam correspondidas com a política de plataformas 'All'. Isso se baseia no cenário em que todos os clientes são selecionados explicitamente e, portanto, nenhum cliente 'desconhecido' é selecionado nesta política específica
Exemplo de tal condição```json "platforms": { "includePlatforms": ["all"], "excludePlatforms": ["macOS"] },
**Referência** https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/concept-conditional-access-conditions#device-platforms
> **Importante** <br> *A Microsoft recomenda que você tenha uma política de Acesso Condicional para plataformas de dispositivos não suportadas. Como exemplo, se você quiser bloquear o acesso aos seus recursos corporativos a partir do Chrome OS ou de qualquer outro cliente não suportado, você deve configurar uma política com uma condição de Plataformas de dispositivos que inclua qualquer dispositivo e exclua as plataformas de dispositivos suportadas e o controle de concessão definido como Bloquear acesso.*
---
#### Diferenças de pesquisa
1. Pesquisa por função
> Quando funções são usadas como condições, a pesquisa de exclusões/inclusões é determinada apenas pela função. Isso pode resultar em uma situação em que a política termina corretamente em uma função, mas o usuário que está nessa função ainda pode ser excluído da política nos resultados. Nos resultados, ambas as condições são destacadas (não mescladas). Isso é puramente uma decisão de design, pois queremos mostrar as terminações de função separadamente, sem contexto de usuário ou grupo.
---
Example:
userID:0cd1b62d-5ff8-497b-9b56-9bb02bc0ab8c is included from All Apps policy
There is admin policy, that covers role of Global administrator, but not the userId.
Both of following conditions would be shown in results:
1. Role GA is excluded individually (1)
2. UserId is not explicitly targeted by group or userId (0)
All (cross-policy) policies matched:1 users:Company Administrator
All (cross-policy) policies matched:0 users:joosua santasalo
---
2. Pesquisa por grupo
> Por outro lado, se grupos forem usados, a terminação da política é mesclada, e assim a exclusão do usuário seria mostrada como terminada pela inclusão do grupo.
Example:
userID:194383eb-6053-4d1e-bc72-f332be6ca2cb is included from All Apps policy
There is policy which targets the user only by group
Following conditions would be shown in results:
1. User is excluded individually
2. User is targeted via group.
All (cross-policy) policies matched:1 users:Vihtori Santasalo (matched via group)
3. Pesquisa por convidado
>Os usuários não são mapeados como convidados nesta versão. Este recurso será introduzido posteriormente, permitindo capturar inclusões/exclusões de userIds de convidados para serem mapeados corretamente para a propriedade ``GuestsOrExternalUsers``.
Atualmente, usuários convidados são mapeados como usuários normais.
>
#### Aninhamento de grupos
>Devido a considerações de desempenho, a profundidade de aninhamento para resolver a associação de grupos só é resolvida uma vez se um grupo for grupo de outro grupo. Caso contrário, há risco de resolver associações indefinidamente, pois um subgrupo pode incluir qualquer um dos grupos raiz, resultando em uma condição de loop sem fim.
Membership:
Group1 -> all members resolved
--> user is member of Group1
--> Group2 is member of Group1 -> all members resolved to Group1
--> Group3 is member of Group1 -> NOT RESOLVED
> Se você ousar... você pode aumentar o aninhamento diretamente no código... [group.js](https://github.com/jsa2/caoptics/blob/main/ca/mainPlugins/userMappers/group.js)

## Parâmetros
Param| Descrição
-|-
``mapping`` | Por padrão, exclusões baseadas em usuário e grupo são avaliadas pelo ID exato dos objetos. Por exemplo, se um objeto é excluído por uma política, ele deve ser encontrado em outra política pelo seu ID exato. <br> Usar `` --mapping`` invoca o MS Graph para preencher o relacionamento entre objetos de uma forma que garanta, por exemplo, que um usuário possa ser excluído por userId em uma política, enquanto a avaliação detecta que o usuário está incluído em outra política por um groupId. <br> ex.: ``--mapping``
``clearMappingCache`` | Limpa os mapeamentos de usuário / grupo recuperados em uma execução anterior <br> ex.: ``--clearMappingCache``
``skipObjectId `` | Remove o ObjectId das permutações. Isso pode ser útil se você quiser excluir a conta break-glass dos resultados <br> ex.: ``--skipObjectId=bcd27e9b-8974-42ec-a2a1-ba2498b45674,c7a4a639-00e7-47e0-aa9d-ea502bbbd382``
``skip `` | Remove a categoria de permutação completa. <br> ex.: ``--skip=users``
``includeReportOnly `` | Permite misturar políticas reportOnly com políticas habilitadas. Remova as políticas existentes antes de executar isso removendo o arquivo policies.json na raiz, ou use a opção ``clearPolicyCache`` <br> ex.: ``--includeReportOnly``
``includeLegacyAuth `` | Por padrão, políticas que possuem apenas condições de autenticação herdada não são avaliadas. Use este sinalizador se você quiser incluir a autenticação herdada na análise <br> observe que incluir a autenticação herdada a analisará em relação a todos os aplicativos, não apenas às cargas de trabalho suportadas (AAD, SPO, EXO) <br> ex.: ``--includeLegacyAuth``
``clearPolicyCache `` | Remove os caches de políticas <br> ex.: ``--clearPolicyCache``
``clearTokenCache `` | Remove os caches de token <br> ex.: ``--clearTokenCache``
``allTerminations`` | Inclui também resultados que terminaram na política <br> ``--allTerminations``
``debug`` | Mostra o uso de memória e a estimativa de progresso <br> ex.: ``--debug``
``altLogin `` | Permite definir um FQDN alternativo para o endpoint de login <br> ex.: ``--altLogin=login.microsoft.com.alt``
``altGraph `` | Permite definir um FQDN alternativo para o endpoint do Graph <br> ex.: ``--altGraph=graph.microsoft.com.alt``
``customPolicyFilter `` | Permite o uso de filtragem personalizada para políticas (recomendado apenas quando as políticas não aderem ao esquema esperado) <br> ex.: ``--customPolicyFilter`` <br> Você pode modificar o filtro selecionando [``customPolicyFilter.js``](https://github.com/jsa2/caoptics/blob/main/ca/mainPlugins/customPolicyFilter.js)
``expand `` | Permite definir um grupo a ser expandido nos resultados. Por padrão, o grupo é expandido para os 10 primeiros itens. A quantidade de itens expandidos pode ser aumentada usando em conjunto a opção ``--expandCount=30``<br> ex.: ``--expand=9c06d103-f5b0-4404-bb25-aec4636912cd,47087cd3-64e9-470b-980a-5662f498e016`` <br> Nota: O uso desta opção exige que o cache de mapeamento seja limpo ``--clearMappingCache``
### Como fornecer parâmetros a partir do launch.json (depuração no VSCode)?
copie o esquema JSON atual e crie um arquivo chamado launch.json na pasta ``.vscode/launch.json`````json
{
"version": "0.2.0",
"configurations": [
{
"type": "node",
"request": "launch",
"name": "Launch Program",
"skipFiles": [
"<node_internals>/**"
],
"program": "${workspaceFolder}/ca/main.js",
//"program": "${file}",
"args": [
"--skipObjectId=259fcf40-ff7c-4625-9b78-cd11793f161f",
"--mapping",
"--clearMappingCache",
"--clearPolicyCache",
"--clearTokenCache",
"--customPolicyFilter",
"--allowPreviewPolicies=beta",
// "--altGraph=graph.microsoft.com",
// "--allPlatforms",
// "--includeReportOnly",
//"--inject",
//"--clearPolicyCache",
// "--skipCleaning",
// "--allTerminations",
// "--aggressive",
"--debug",
],
"runtimeArgs": [
"--max-old-space-size=4096"
]
}
]
}
Antes de executar a ferramenta pela primeira vez```sh #Navigate to the cloned folder cd caOptics; #Install depedencies npm install
Cada execução iniciará o login se nenhuma sessão estiver armazenada. Se você tiver uma sessão no Azure CLI e quiser usar outra sessão, então, no Azure CLI, execute ``Az Account Clear``
1. Execução estática (sem [mapeamento](#parameters) )
>``node ./ca/main.js ``
2. Execução estática (com [mapeamento](#parameters) )
>``node ./ca/main.js --mapping``
3. Fornecendo ``skipObjectId=yourID`` para excluir o grupo Break glass
>``node ./ca/main.js --mapping --skipObjectId=259fcf40-ff7c-4625-9b78-cd11793f161f``
Além disso, se você estiver experimentando a ferramenta, é recomendável incluir ``--clearPolicyCache --clearTokencache`` como parâmetro. Isso removerá os tokens de sessão existentes e o policy.json (cache)
>remova o policies.json da pasta do projeto, se você não quiser remover a sessão do cache, mas apenas quiser que as políticas sejam removidas
**Saída esperada (com base nos dados de exemplo)**
Policy | Permutation | Terminations | lookup
-|-|-|-
All (cross-policy)| 33a51ecbcc58466a90b6bea66b239c74| 0| Locations:10a25087-9bf6-479b-a2a1-37e814310c90 -> Platforms:macOS -> clientAppTypes:mobileAppsAndDesktopClients -> users:All
All (cross-policy)| 4194a5e64e054764bd8774d4992887b9| 0| Locations:10a25087-9bf6-479b-a2a1-37e814310c90 -> Platforms:macOS -> clientAppTypes:mobileAppsAndDesktopClients
All (cross-policy)| 24f38821ea8e4331aeae7c078a727236| 1| Locations:10a25087-9bf6-479b-a2a1-37e814310c90 -> Platforms:macOS
## Visualização de relatórios
Todas as execuções bem-sucedidas produzem ``crosstable.md`` (uma tabela markdown) e o csv ``report.csv``
- Cada nova execução da ferramenta apagará o relatório anterior
**Exemplo de relatório .csv**```
users Applications clientAppTypes Platforms locations terminations
----- ------------ -------------- --------- --------- ----------
GuestsOrExternalUsers All browser macOS finland 0
user-Joosua Santasalo All browser macOS finland 0
user-Joosua Santasalo All mobileAppsAndDesktopClients macOS finland 0
All All browser macOS finland 0
Exemplo de dump .json```json [ { "policy": "all", "lineage": "Platforms:macOS -> clientAppTypes:browser -> users:All -> Locations:10a25087-9bf6-479b-a2a1-37e814310c90 -> ", "lookup": "Locations:10a25087-9bf6-479b-a2a1-37e814310c90", "terminated": [] }, { "policy": "all", "lineage": "Platforms:macOS -> clientAppTypes:browser -> users:GuestsOrExternalUsers -> Locations:10a25087-9bf6-479b-a2a1-37e814310c90 -> ", "lookup": "Locations:10a25087-9bf6-479b-a2a1-37e814310c90", "terminated": [] } ]
## Solução de problemas
- Se você estiver usando a AZ CLI para login de sessão, comece com ``az account clear``
- Ao executar a ferramenta, adicione ``--clearPolicyCache --clearTokencache`` para limpar os caches (tokens, políticas e localizações)
- remova manualmente os arquivos policies.json e namedLocations.json existentes da raiz do projeto (se você não estiver usando a opção ``--clearPolicyCache --clearTokencache`` )
- Se as inclusões de Grupo não parecerem funcionar, certifique-se de que ``--mapping`` esteja selecionado e de que não haja aninhamento além de dois grupos
---
**Testes no Azure Cloud Shell**
Se você estiver testando esta solução em um ambiente maior. Ative ``--debug`` nos parâmetros e, se possível, aumente o tamanho do heap do Node para `` --max-old-space-size=4096 ``
- A experiência de testes mostrou que a quantidade de permutações pode atingir números bastante altos em ambientes grandes. Executar com o modo de depuração pode ajudar a apontar onde o problema pode ocorrer. Em tais cenários, usar o Cloud Shell pode não ser viável (embora o algoritmo de permutação agora tenha reduzido enormemente o uso de memória, não consegui confirmar que o Cloud Shell funcionaria em ambientes grandes)
> Uma vez que o algoritmo atual para geração de permutações é muito reduzido em relação ao original, até o Cloud Shell deveria funcionar, mas, por exemplo, condições de corrida ou outros vazamentos de memória ainda podem estar à espreita em algum lugar e se manifestar em ambientes maiores, mitigando os benefícios do algoritmo atual.
``node --max-old-space-size=4096 ./ca/main.js --mapping --skipObjectId=259fcf40-ff7c-4625-9b78-cd11793f161f --clearPolicyCache --debug``
---
- Você pode ter referências vazias nas políticas de CA e a pesquisa mostrará, portanto, uma condição não finalizada.
>
# Contribuição
Abra um pull request ou envie uma issue, dependendo do escopo da solicitação.