O QUE É UM SID?

Início // O QUE É UM SID? Breve descrição do que é um Security IDentifier em ambiente Microsoft Windows

Criado por José Proença,

Agosto 6, 2025
15:36

O QUE É UM SID? Breve descrição do que é um Security IDentifier em ambiente Microsoft Windows

Índice

1. O que é um SID?

Um SID (Security Identifier) é como um número de identificação único que o Microsoft Windows usa para identificar utilizadores, grupos e outros objetos de segurança no sistema.
Pense no SID como o número de cartão de cidadão, único para cada cidadão, e que nos identifica nos vários serviços e repartições. No Microsoft Windows a filosofia é idêntica, o SID identifica o utilizador perante o sistema. Mesmo que se mude o nome do utilizador, o SID continua o mesmo. E é exatamente isso que o sistema realmente usa para saber quem é.

1.1. Exemplo prático de um SID

Por exemplo, a Susana Alves pode ter o SID:
S-1-5-21-1234567890-2345678901-3456789012-1001
Mesmo que se mude o nome “susana.alves” para “maria.alves”, o SID1 continua igual. É esse SID (essa identificação) que o Microsoft Windows usa para identificar, atribuir permissões, aceder a ficheiros, etc.

1.2. SID e permissões no sistema

Um SID (Security Identifier) por si só não tem permissões associadas diretamente. Ele é apenas um identificador único. No entanto, o SID é usado pelo Windows para atribuir e verificar permissões em objetos como ficheiros, pastas, serviços, chaves de registo, etc.
Assim, as permissões são atribuídas a SID’s, não aos nomes dos utilizadores.

Quando um utilizador tenta aceder a um recurso, o Windows verifica se o SID desse utilizador está listado nas ACL’s (Access Control Lists) do recurso.
A ACL define o que determinado SID pode fazer: ler, escrever, modificar, apagar, etc.

1.3. Verificação do SID

Para verificarmos o SID de um utilizador com o comando “whoami”, na linha de comandos (CMD), escrevemos:
whoami /user

Se desejar pode correr, desta vez em Powershell (PS) o comando:
Get-WmiObject Win32_UserAccount | Where-Object { $_.Name -eq $env:USERNAME } | Select-Object Domain, Name, SID

Também em powershell pode verificar o SID de todos os utilizadores locais:
Get-LocalUser | Select-Object Name, SID

Pode ainda ver o SID de um utilizador local específico:
Get-LocalUser -Name “Username” | Select-Object Name, SID
(Substituir “Username” pelo nome do utilizador)

Para verificar qual o SID do utilizador atualmente ligado podemos executar o seguinte comando
[System.Security.Principal.WindowsIdentity]::GetCurrent().User.Value

Quando estamos em ambiente de floresta/domínio podemos ver o SID de um utilizador de domínio através do comando:

$objUser = New-Object System.Security.Principal.NTAccount(“domain\user”)
$strSID =$objUser.Translate([System.Security.Principal.SecurityIdentifier])
$strSID.Value
(Substituir “domain\user” pelo domínio\nome do utilizador)

Também em ambiente de floresta/domínio podemos usar a Active Directory Users and Computers (ADUC) com a extensão Attribute Editor ativada:
Abrir as propriedades de um utilizador.
Ir ao separador Attribute Editor.
Procurar o atributo objectSID.

2. O SID no Microsoft Windows 11

O Microsoft Windows possui dois tipos principais de contas de Administrator:

A conta de Administrator (built-in) e as contas criadas pelo utilizador com privilégios administrativos.
Embora ambas possam executar tarefas administrativas estas contas diferem em funcionalidade, segurança e uso pretendido. A conta de Administrator (built-in) tem como finalidade a execução de tarefas de configuração e recuperação do sistema.
Status por defeito: Desativada por defeito no Windows 11 para aumentar a segurança e diminuir a superfície de ataque.
Controle de Conta de utilizador (UAC): Os prompts do UAC são desativados, permitindo operações sem confirmação.
Identificador de Segurança (SID): Possui um SID conhecido2 (S-1-5-domain-500), tornando-o um alvo potencial para ataques.
Gestão de contas: Não pode ser excluído ou bloqueado, mas pode ser renomeado ou desativado.
Riscos de segurança: Devido aos seus privilégios elevados e SID conhecido, recomenda-se manter esta conta desativada durante o uso regular.

3. Contas de Administrator criadas pelo utilizador

Finalidade: Destinadas a tarefas administrativas diárias e de uso geral.
Status padrão: Criadas durante a instalação do Windows ou adicionadas posteriormente. Estão ativas por defeito.
Controle de Conta de Utilizador (UAC): Os prompts do UAC são ativados, exigindo confirmação para ações administrativas, o que adiciona uma camada de segurança.
Identificador de Segurança (SID): Cada conta possui um SID3 exclusivo, reduzindo a previsibilidade.
Gestão de contas: Podem ser excluídos, desativados ou ter os seus privilégios modificados.
Práticas de segurança: É recomendável usar uma conta de utilizador padrão para atividades diárias e usar privilégios administrativos somente quando necessário.

4. Casos de uso para a conta Administrator built-in

A ativação da conta de Administrator built-in no Windows 11 não é geralmente recomendada devido a questões de segurança.
No entanto, existem cenários específicos em que a ativação desta conta se torna necessária, por exemplo:
Recuperação do Sistema quando outras contas de Administrator estão inacessíveis:
Se todas as contas de Administrator predefinidas forem desativadas, eliminadas ou as suas palavras-passe forem esquecidas, a conta de Administrator built-in pode servir como uma ferramenta de recuperação vital. Por exemplo, se ocultou a sua conta de Administrator principal através do registo e não consegue aceder, ativar a conta de Administrator built-in permite-lhe iniciar sessão e corrigir o problema;

Ignorar o Controlo de Conta de Utilizador (UAC) para solução de problemas avançada;
A conta de Administrator built-in opera com privilégios elevados e não solicita confirmações de UAC. Isto pode ser particularmente útil quando se resolvem problemas profundos ao nível do sistema ou se instala software que exija direitos administrativos totais sem interrupções. No entanto, é crucial utilizar esta funcionalidade com cautela para evitar alterações não intencionais no sistema.
Configuração de pré-implementação no Modo de Auditoria
Durante a configuração de novos sistemas, especialmente em ambientes empresariais, os Administrators podem utilizar a conta de Administrator built-in no Modo de Auditoria para instalar aplicações, controladores ou definir parâmetros antes do sistema ser entregue aos utilizadores finais. Esta conta facilita a configuração sem as restrições impostas pelo UAC ou outras limitações de conta de utilizador.

5. Ativar a conta de Administrator built-in

5.1. No prompt de comando (CMD):

A forma mais rápida e prática de se ativar a conta de Administrator do Windows 11 é utilizando a linha de comandos com privilégios administrativos:
net user Administrator /active:yes

Para definir ou alterar a palavra-passe da conta de Administrator built-in interactivamente:
net user Administrator *

1. (Verificar se tem o Microsoft Windows em EN (Administrator) ou em PT (Administrador).
2. (Se escrever o comando net user Administrator(dor) o sistema devolve alguns parâmetros relativos a este objeto (Nome, País, onde pode fazer logon, perfil, last logon, associação a grupos, etc).
Após executar este comando, ser-lhe-á pedido que introduza uma nova password e que a confirme. Este método garante que a palavra-passe não é visível no ecrã, aumentando a segurança.

5.2. Através da Gestão do Computador

1.º Abra a Gestão do Computador (por exemplo, clicando com o botão direito do rato no menu Iniciar).
2.º Navegue até Utilizadores e Grupos Locais → Utilizadores.
3.º Clique duas vezes em Administrator.
4.º Desmarque a opção “Conta desativada” e confirme.

Ativar a conta de Administrator no Microsoft Windows 11 através do Computer Management
Esta abordagem é mais adequada para máquinas geridas localmente ou para sistemas autónomos. Requer, no entanto, login local no computador, o que geralmente não é viável em redes empresariais.

6. Através de Política de Grupo (GPO)

Podemos ativar a conta de Administrator built-in através da Política de Grupo (GPO) em redes maiores. Aceda à consola de gestão da Política de Grupo através de Ferramentas no Gestor do Servidor no Microsoft Windows Server.
De seguida, crie uma nova política e designe o seu destino, como por exemplo uma Unidade Organizacional (UO) específica.
No Editor de Política de Grupo, defina as seguintes definições:
• Caminho: Configuração do Computador → Definições do Windows → Definições de Segurança → Políticas Locais → Opções de Segurança
• Política a ativar: Contas: Estado da conta de Administrator (Definir como Enabled)

Activar a conta de Windows 11 administrator via Group Policy

7. Com o PowerShell

Pode ativar a conta de Administrator do Windows utilizando o PowerShell.
Na consola do Windows PowerShell, com privilégios administrativos, execute o seguinte comando:
Enable-LocalUser -Name “Administrator”
Set-LocalUser -Name “Administrator” -Password (Read-Host -AsSecureString “Enter password”)
Este método é adequado para implementações ou automatizações baseadas em scripts.

Principais aspetos de segurança:
Ative sempre a Active Directoryministrador built-in com cautela, pois esta conta tem acesso privilegiado. Preste ainda atenção aos seguintes aspetos de segurança:

Ativação temporária apenas
Ative a conta de Administrator apenas durante o período em que realmente necessitar dela. A ativação permanente aumenta a superfície de ataque, especialmente com a exposição da rede desprotegida.
net user Administrator /active:no

Defina uma palavra-passe forte
Deve definir uma senha segura. Utilize palavras-passe complexas e longas e armazene-as numa ferramenta de gestão de palavras-passe.

Auditoria e monitorização:
Recomenda-se ativar o registo em log para Administrators em Política de Grupo: Política de Auditoria > Auditar eventos de início de sessão. Além disso, se possível, implemente uma solução SIEM ou outras ferramentas de monitorização para verificar as atividades da Active Directoryministrador.

Restringir o acesso remoto
Evite utilizar a conta de Administrator para acesso remoto. Em vez disso, utilize contas administrativas dedicadas com menos privilégios, que pode estender através de controlos de acesso Just-in-Time.

8. TIP #1 – Eliminação de um utilizador

Mesmo que você elimine um utilizador e crie outro com o mesmo nome e as mesmas referências (Pais, Departamento, etc), o novo utilizador terá (sempre!) um SID diferente. Isto garante que permissões antigas não sejam herdadas indevidamente.

9. TIP #2 – Sistemas operativos onde pode existir SID ou equivalente

O conceito de SID (Security Identifier) é específico do ecossistema Windows, mas outros sistemas operativos podem ter conceitos semelhantes ou até mesmo usar SID’s em contextos específicos, especialmente quando existe integração com o Windows ou Active Directory.

9.1. Windows (todas as versões)

SID é nativo. Cada utilizador, grupo, computador e entidade de segurança recebe um SID único.
É usado para controle de acesso (ACLs), permissões e auditoria.

9.2. Linux (Debian, Ubuntu, CentOS, Fedora, etc.)

Não usa SID’s nativamente. Pode usar SID’s em:
Samba: para interoperar com domínios Windows.
SSSD: ao integrar com Active Directory.
SELinux: usa identificadores internos semelhantes a SID’s (não compatíveis com Windows).

9.3. Unix (FreeBSD, OpenBSD, NetBSD, etc.)

Não possui SID’s nativos. Pode lidar com SID’s em:
Samba: ao atuar como servidor de arquivos para clientes Windows.
Integração com AD: via Kerberos/LDAP.

9.4. macOS

Não usa SID’s nativamente. Pode lidar com SID’s quando:
Integrado a um domínio Active Directory.
Usando SSSD ou LDAP com mapeamento de SID’s.

9.5. Android

Baseado em Linux, não usa SID’s. Usa UIDs e SELinux para controle de acesso.
SELinux no Android também usa identificadores internos, mas não são SID’s no sentido do Windows.

9.6. Solaris (Oracle Solaris)

Não usa SID’s nativamente. Pode usar RBAC (Role-Based Access Control) e UIDs/GIDs.
Pode interoperar com AD via LDAP/Kerberos, onde SID’s podem ser mapeados.

9.7. Sistemas integrados com Active Directory (independente do SO)

Qualquer sistema que se integre com o Active Directory pode lidar com SID’s, mesmo que não os use nativamente.
São exemplos disto as appliances de rede, firewalls, NAS (como Synology, QNAP), etc.

10. TIP #3 – Os PC’s também possuem SID’s?

Os computadores em sistemas Microsoft também possuem um SID (Security Identifier).
Quando um computador com Windows é instalado ou passa a fazer parte de um domínio, o sistema gera um SID exclusivo para identificar esse computador. Esse SID é usado para:
•Identificar o computador de forma única numa rede ou domínio;
•Controlar permissões e políticas de segurança aplicadas ao computador;
•Gerir perfis de utilizador locais e objetos de segurança.

11. TIP #4 – Clonagem de Sistemas e Problemas com SID’s

Se se clona um sistema Windows (por exemplo, usando uma imagem de disco), o SID do computador clonado será o mesmo do original, o que pode causar:
• Conflitos em redes ou domínios.
• Problemas com políticas de grupo (GPOs).
• Dificuldades em identificar máquinas de forma única.

Por isso, ferramentas como o Sysprep (System Preparation Tool) são usadas para gerar um novo SID ao preparar uma imagem para ser usada em múltiplos computadores.

12. O SID faz parte da Identity?

Sim, o SID (Security Identifier) faz parte da identity no contexto de sistemas Microsoft, especialmente no Windows e no Active Directory.
No ecossistema Microsoft, identity refere-se ao conjunto de atributos que identificam de forma única um utilizador, grupo, computador ou serviço dentro de um sistema ou rede. Isso inclui:
Nome de utilizador (ex: susana.alves)
Domínio (ex: empresa.local)
SID (ex: S-1-5-21-…)
Credenciais (senha, certificados, etc.)
Claims (em sistemas modernos como Azure AD)
O SID é o identificador único e imutável que representa a identidade de um objeto de segurança no sistema. Conforme já referido, mesmo que o nome de utilizador mude, o SID permanece o mesmo, garantindo:
•Persistência de permissões (ACLs continuam válidas);
•Rastreio confiável de identidades;
•Segurança baseada em identidade.

13. Em Entra id também existem SID’s?

Sim, o Microsoft Entra ID (antigo Azure Active Directory) também utiliza SID’s, mas de forma um pouco diferente da Active Directory tradicional.
No Entra ID os objetos de identidade (como utilizadores e grupos) têm identificadores únicos, mas o SID é usado principalmente quando existe integração com ambientes híbridos, como:

1. Ambientes Híbridos (Azure AD + Active Directory local)
Quando um utilizador do Active Directory local é sincronizado com o Entra ID (via Azure AD Connect), o SID do AD local é preservado como um atributo chamado: onPremisesSecurityIdentifier
Isso permite que o Entra ID reconheça e mantenha a identidade do utilizador em ambos os ambientes.

2. Autenticação e Autorização
O SID pode ser incluído em tokens de acesso (como JWTs)4 emitidos pelo Entra ID, especialmente em cenários híbridos ou com aplicações legadas que dependem de SID’s.

14. Como é que os SID’s funcionam no Entra ID?

14.1. SID em ambientes híbridos:

1. Quando você sincroniza utilizadores da Active Directory local com o Entra ID usando o Microsoft Entra Connect, o SID da AD local é preservado e armazenado no atributo onPremisesSecurityIdentifier no Entra ID.
2. Isso permite que sistemas e políticas que dependem do SID continuem a funcionar, mesmo depois da migração para Cloud.

14.2. SID baseado em sessão (Session ID):

O Entra ID também usa um tipo de SID chamado identificador baseado em sessão para rastrear e correlacionar tokens de autenticação (como tokens de acesso, atualização e cookies de sessão) emitidos durante uma única sessão de login.
Esse SID é incluído nos tokens e logs, permitindo que analistas de segurança rastreiem atividades de um utilizador em diferentes serviços e sessões.

14.3. Conversão entre SID e Object ID:

O Entra ID não armazena SID’s da mesma forma que a AD tradicional, usa Object IDs (GUIDs).

Existem scripts e funções (como ConvertToSid() e ConvertToObjectId()) que permitem converter entre um Object ID e um SID compatível com Entra ID.

14.4. Tipos de SID utilizados no Entra ID

Tipo de SID	Onde é usado	Observações
SID da Active Directory local	Em ambientes híbridos	Armazenado no atributo onPremisesSecurityIdentifier
SID de sessão	Tokens e logs do Entra ID	Usado para rastreio de sessões e auditoria
SID convertido	A partir de Object ID	Pode ser gerado para compatibilidade com sistemas legados

14.4.1. Verificação SID local com PowerShell

Já sabemos que, por powershell, podemos consultar o SID (local) com o comando:
Get-LocalUser -Name “username” | Select-Object Name, SID

14.4.2. Verificação SID em Active Directory

Em Active Directory podemos usar o comando:
Get-ADUser -Identity “username” -Properties SID | Select-Object SamAccountName, SID

(Este commando requer o módulo ActiveDirectory. Execute Import-Module ActiveDirectory se necessário.).

14.4.3. Verificação SID no Entra ID (Azure AD)

Em Entra ID podemos correr o comando powershell:
Get-AzureADUser -ObjectId “email@dominio.com” | Select-Object DisplayName, ObjectId
Ou
Get-MgUser -UserId “email@dominio.com” | Select-Object DisplayName, Id

(Este commando requer o módulo AzureAD ou Microsoft.Graph.
Pode ser instalado com:
Install-Module AzureAD
# ou
Install-Module Microsoft.Graph)

Em AD podemos obter muitos detalhes além do Object ID dos utilizadores no PowerShell, especialmente se estiver usando os módulos corretos para Active Directory local ou Microsoft Entra ID (Azure AD).

Seguem abaixo algumas referências práticas para cada cenário:
Active Directory Local (com Get-ADUser)
Use o seguinte comando para obter todos os atributos disponíveis de um utilizador:
Get-ADUser -Identity “username” -Properties * | Format-List

Este comando vai devolver o SID, DistinguishedName, SamAccountName, DisplayName, EmailAddress, LastLogonDate, MemberOf (grupos) e mais alguns atributos da AD

Microsoft Entra ID (Azure AD)
Com o módulo AzureAD podemos usar o comando PS:
Get-AzureADUser -ObjectId “email@dominio.com” | Format-List
Ou (Com o módulo mais moderno Microsoft.Graph):
Get-MgUser -UserId “email@dominio.com” | Format-List

Esse commando devolve: Id (Object ID), DisplayName, UserPrincipalName, Mail, AccountEnabled, JobTitle, Department, AssignedLicenses, SignInActivity (com permissões adicionais)
Expandir atributos personalizados:
Se desejar atributos adicionais (como onPremisesSecurityIdentifier, Manager, SignInActivity, etc.), use:
Get-MgUser -UserId “email@dominio.com” -Property
“DisplayName,Id,UserPrincipalName,SignInActivity,onPremisesSecurityIdentifier” | Format-List
(Para usar Get-MgUser, você precisa estar conectado com: Connect-MgGraph -Scopes “User.Read.All”“)

15. Identificadores principais no Entra ID

Além do SID (quando aplicável), o Entra ID usa:
• objectId: Identificador único global no Entra ID.
• userPrincipalName (UPN): Nome de login do utilizador.
• immutableId: Usado para mapear utilizadores sincronizados do AD local.
• onPremisesSecurityIdentifier: O SID do AD local, se houver.

16. Conclusão

Em sistemas Microsoft Windows o utilizador é referenciado por uma identificação denominada Security IDentifier (SID).
Ativar a conta de Administrator built-in no Windows 11 é essencial para tarefas administrativas específicas, como a recuperação do sistema ou implementação de definições.
No entanto, para manter a segurança do sistema, é crucial ativar esta conta apenas quando necessário, definir uma palavra-passe forte e desativá-la imediatamente após a utilização.
Em Entra ID este princípio mantém-se.
O role equivalente ao role de Administrator (como no Active Directory on-premisses) é o Global Administrator.
Global Administrator (Administrador Global)
• Equivalente ao: Administrador do domínio no AD local.
• Permissões: Controle total sobre todas as funcionalidades do Entra ID.

Pode:
•Gerir utilizadores e grupos;
•Atribuir papéis administrativos;
•Configurar políticas de segurança;
•Gerir domínios e integrações com serviços Microsoft 365, Intune, etc;
•Fazer reset às passwords de qualquer utilizador, incluindo outros administradores.

Para uma visão mais ampla sobre como decisões estratégicas relacionadas com cloud, self-hosted e segurança afetam a gestão de identidades nas empresas, leia também:
IA na empresa: ad hoc ou orientada por estratégia? Talvez nem tudo deva ficar na cloud

17. Bibliografia

Criado por José Proença

Últimos Artigos

Destaques

Subscreva a nossa Newsletter

Receba todas as novidades GTI na sua caixa de correio eletrónico