Perguntas[ldap](server)

O SO é Amazon Linux 2023. Estou tentando usar LDAP para fazer gerenciamento de usuários/grupos para todos os novos usuários. Eu instalei os pacotes openldap-servers, openldap-clients e nss-pam-ldapd. Eu configurei SSL no slapd e

ldapwhoami -x -H ldaps://myserver.mydomain.com
ldapwhoami -x -H ldapi:///

ambos retornam anônimos.

sudo ldapwhoami -H ldapi:///

retorna dn:gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth.

Eu configurei nsswitch.conf para:

passwd:       ldap sss files
shadow:       ldap files
group:        ldap sss files

Eu configurei nslcd.conf para:

uid root
gid root
uri ldapi:///
base dc=mydomain,dc=com

Quando eu corro:

sudo useradd -b /home balaguru1

não parece adicionar o usuário ao banco de dados LDAP. Os arquivos em /var/lib/ldap/ não são alterados. /etc/passwd é modificado com o novo usuário.

O que estou perdendo?

Normalmente, para consultar o servidor OpenLDAP, estou usando a seguinte consulta

ldapsearch -x -H ldap://host -b dc=domain,dc=com uidNumber=4158

Mas recentemente vi outra maneira de consultar

ldapsearch -x -H ldap://host -b o=domain.com uidNumber=4158

O que é esse formato "o=" e como devo configurar meu servidor LDAP para usá-lo?

Obrigado!

Estou no Fedora e configurei um servidor OpenLDAP. Não me lembro de ter definido uma senha de administrador para começar, mas estou tendo que realizar operações nas quais a senha de administrador é solicitada. Não inserir nada não funciona. Fiz uma extensa pesquisa sobre o problema e tentei o seguinte:

$ ldapmodify -Q -Y EXTERNAL -H ldapi:/// << E0F
dn: olcDatabase={1}mdb,cn=config
changetype: modify
replace: olcRootPW
olcRootPW: {SSHA}wDiv2teFapZFmOwSz04/2CMaYvpqfLvi
E0F
modifying entry "olcDatabase={1}mdb,cn=config"
ldap_modify: Insufficient access (50)

$ sudo -i
[sudo] password for User: 
[root@localhost ~]# ldapmodify -Q -Y EXTERNAL -H ldapi:/// << E0F
dn: olcDatabase={1}mdb,cn=config
changetype: modify
replace: olcRootPW
olcRootPW: {SSHA}wDiv2teFapZFmOwSz04/2CMaYvpqfLvi
E0F
modifying entry "olcDatabase={1}mdb,cn=config"
ldap_modify: Insufficient access (50)

$ ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b  cn=config olcRootDN=cn=admin,dc=com,dc=example  dn olcRootDN olcRootPW
SASL/EXTERNAL authentication started
SASL username: gidNumber=1000+uidNumber=1000,cn=peercred,cn=external,cn=auth
SASL SSF: 0
No such object (32)

$ sudo ldapsearch -H ldapi:/// -Y EXTERNAL -b 'cn=config'
[sudo] password for User: 
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
# extended LDIF
#
# LDAPv3
# base <cn=config
> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# search result
search: 2
result: 32 No such object

# numResponses: 1

$ sudo ldapmodify -Q -Y EXTERNAL -H ldapi:/// << E0F
dn: olcDatabase={1}mdb,cn=config
changetype: modify
replace: olcRootPW
olcRootPW: {SSHA}wDiv2teFapZFmOwSz04/2CMaYvpqfLvi
E0F
modifying entry "olcDatabase={1}mdb,cn=config"
ldap_modify: Insufficient access (50)

Também coloquei o acima em um arquivo e tentei o seguinte:

$ vim pw_reset.ldif
$ sudo ldapmodify -Y EXTERNAL -D 'cn=config' -H ldapi:/// -f ./pw_reset.ldif 
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "olcDatabase={1}mdb,cn=config"
ldap_modify: Insufficient access (50)

Portanto, o problema óbvio aqui é que não importa o que aconteça, parece que não tenho "acesso suficiente", que é o problema aqui. Preciso da senha do administrador para definir a senha do administrador. Qual é a maneira correta de fazer isso?

Configurei o ldap na instância do Jboss, porém ele não está conectado ao servidor ldap e gera o erro abaixo.

02:50:08,512 DEBUG [org.wildfly.security] (management task-1) Obtaining lock for identity [user1]...
02:50:08,513 DEBUG [org.wildfly.security] (management task-1) Obtained lock for identity [user1].
02:50:08,517 DEBUG [org.wildfly.security] (management task-1) Creating [class javax.naming.directory.InitialDirContext] with environment:
02:50:08,517 DEBUG [org.wildfly.security] (management task-1)     Property [java.naming.security.credentials] with value [******]
02:50:08,517 DEBUG [org.wildfly.security] (management task-1)     Property [java.naming.security.authentication] with value [simple]
02:50:08,518 DEBUG [org.wildfly.security] (management task-1)     Property [java.naming.provider.url] with value [ldap://ldap_server:3268]
02:50:08,518 DEBUG [org.wildfly.security] (management task-1)     Property [com.sun.jndi.ldap.read.timeout] with value [60000]
02:50:08,518 DEBUG [org.wildfly.security] (management task-1)     Property [com.sun.jndi.ldap.connect.pool] with value [false]
02:50:08,518 DEBUG [org.wildfly.security] (management task-1)     Property [com.sun.jndi.ldap.connect.timeout] with value [5000]
02:50:08,518 DEBUG [org.wildfly.security] (management task-1)     Property [java.naming.security.principal] with value [CN=svc_account,OU=IT,DC=local,DC=xxx,DC=xxx]
02:50:08,518 DEBUG [org.wildfly.security] (management task-1)     Property [java.naming.referral] with value [ignore]
02:50:08,519 DEBUG [org.wildfly.security] (management task-1)     Property [java.naming.factory.initial] with value [com.sun.jndi.ldap.LdapCtxFactory]
02:50:08,536 DEBUG [org.wildfly.security] (management task-1) Could not create [class javax.naming.ldap.InitialLdapContext]. Failed to connect to LDAP server.: javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C090449, comment: AcceptSecurityContext error, data 52e, v3839]

Atualmente estou configurando o slapd como proxy e enfrentando o desafio de reescrever atributos LDAP. Estou ciente do recurso do módulo de reescrita (rwm) para DNs, mas preciso aplicar funcionalidade semelhante aos atributos LDAP.

Contexto : Nossos IDs de usuário são estruturados com um prefixo de uma ou duas letras não essenciais seguidas de 8 a 9 dígitos importantes. Meu objetivo é retirar essas letras e utilizar os dígitos restantes para atribuir IDs de usuário/grupo POSIX por meio de nslcd/sssd. Infelizmente, modificações no servidor LDAP original não são uma opção, pois os administradores não estão abertos a alterações.

Problema : Apesar de vários dias de pesquisas e testes, incluindo recursos de consultoria e uso do ChatGPT, só consegui reescrever os DNs. Estou procurando entender se é possível usar a funcionalidade de reescrita para atributos diferentes de DNs e, em caso afirmativo, como conseguir isso.

Tentativas :

Tentei usar o mapa de banco de dados e o ldap com a sobreposição de rwm para manipular atributos. Minhas configurações reescreveram apenas DNs com êxito, mas não outros atributos.

Exemplo da última tentativa:

...
moduleload      back_ldap
moduleload      back_meta
database meta
...
rebind-as-user  true
rewriteEngine on

rewriteContext searchResult
rewriteRule "^(uid=[a-zA-Z]*)([0-9]*)(,.*)$" "$1$2$3,posixUID=$2" ":@"

Questões :

• É possível reescrever atributos LDAP usando o rwm no slapd?
• Se sim, como posso configurar isso para retirar caracteres específicos dos atributos de ID do usuário e reter os dígitos?

Qualquer orientação ou exemplos seriam muito apreciados. Obrigado!

Meu departamento está mudando para usar sssd com ldap para logins em todos os nossos hosts Linux. Tudo está funcionando, mas havia um problema que eu esperava resolver antes de continuar os testes em nosso ambiente de desenvolvimento. Especificamos os grupos ldap que podem efetuar login usando a opção ldap_access_filter e isso funciona conforme o esperado, mas parece ser possível para usuários com acesso root mudar para usuários ldap (usando su do root) que devem ser impedidos de efetuar login usando o ldap_access_filter. Eu gostaria de não permitir a troca de usuários ou a obtenção de informações por meio do comando id para esses usuários que não precisam de acesso às máquinas com as quais estou preocupado. É possível evitar que isso aconteça modificando meu ldap_search_base, ldap_user_search_base ou ldap_group_search_base ou talvez algum outro método.

Esta é minha configuração sssd

[sssd]
#debug_level = 9
config_file_version = 2
services = nss, pam
domains = domain.edu

[pam]
#debug_level = 9
offline_credentials_expiration = 30

[domain/domain.edu]
#debug_level = 9
id_provider = ldap
auth_provider = ldap
access_provider = ldap
ldap_schema = rfc2307bis
ldap_uri = ldaps://sub.domain.edu:636
ldap_search_base = ou=people,o=cuid
ldap_default_bind_dn = cn=svcaccount,ou=proxy,o=cuid
ldap_access_order = filter
ldap_access_filter = groupMembership=cn=devtest,ou=groups,ou=people,o=cuid
ldap_default_authtok_type = obfuscated_password
ldap_default_authtok = [redacted]
ldap_tls_cacert = /etc/openldap/certs/devldap.pem
ldap_tls_reqcert = never
enumerate = true
cache_credentials = True
account_cache_expiration = 30
entry_cache_timeout = 14400
subdomain_inherit = ignore_group_members, ldap_purge_cache_timeout
ignore_group_members = True
ldap_purge_cache_timeout = 0
access_provider = ldap

Eu configurei um Samba4 AD DC e posso autenticar com sucesso com meu Administratorusuário a partir do código .net:

var directoryIdentifier = new LdapDirectoryIdentifier("127.0.0.1", 636);
var credentials = new NetworkCredential($"CN=Administrator,CN=Users,DC=ldap,DC=test,DC=dev", "admin1234!");
using(var connection = new LdapConnection(directoryIdentifier, credentials)) 
{
    try 
    {
        connection.SessionOptions.ProtocolVersion = 3;
        connection.SessionOptions.SecureSocketLayer = true;
        connection.SessionOptions.ReferralChasing = ReferralChasingOptions.None;

        connection.AuthType = AuthType.Basic;

        connection.Bind(credentials);
    }
}

Então com esta conexão, crio um novo usuário:

        var addRequest = new AddRequest(
            "CN=testuser,CN=Users,DC=ldap,DC=test,DC=dev",
            new DirectoryAttribute("objectClass", new object[] { "user" }),
            new DirectoryAttribute("cn", "testuser"),
            new DirectoryAttribute("uid", "testuser"),
            new DirectoryAttribute("sAMAccountName", "testuser"),
            new DirectoryAttribute("unicodePwd", Encoding.Unicode.GetBytes($@"""pw1234!"""))
        );
        var addResponse = connection.SendRequest(addRequest);

        Console.WriteLine($"[ADD] response: {addResponse.ErrorMessage}");

ou fazendo o mesmo no terminal:

ldapadd -H LDAPS://127.0.0.1:636 -D "CN=Administrator,CN=Users,DC=ldap,DC=test,DC=dev" -w admin1234!
dn: CN=testuser,CN=Users,DC=ldap,DC=test,DC=dev
objectClass: user
cn: testuser
uid: testuser
unicodePwd:: IgBwAHcAMQAyADMANAAhACIA
sAMAccountName: testUser

de onde obtive o unicodePwd echo -n "\"pw1234\!\"" | iconv -f UTF-8 -t UTF-16LE | base64.

No entanto, ao tentar autenticar com este usuário:

var testUser_directoryIdentifier = new LdapDirectoryIdentifier("127.0.0.1", 636);
var testUser_credentials = new NetworkCredential($"CN=testuser,CN=Users,DC=ldap,DC=test,DC=dev", "pw1234!");
using(var connection = new LdapConnection(testUser_directoryIdentifier, testUser_credentials)) 
{
    try 
    {
        connection.SessionOptions.ProtocolVersion = 3;
        connection.SessionOptions.SecureSocketLayer = true;
        connection.SessionOptions.ReferralChasing = ReferralChasingOptions.None;

        connection.AuthType = AuthType.Basic;

        connection.Bind(testUser_credentials);
    }
}

Eu recebo o erro:

A credencial fornecida é inválida. [Código de erro 49]

Da mesma forma, para o comando do terminal

ldapwhoami -vvv -H ldaps://127.0.0.1:636 -D "CN=testuser,CN=Users,DC=ldap,DC=test,DC=dev" -x -w pw1234\! 

eu recebo

ldap_bind: Credenciais inválidas (49) informações adicionais: 80090308: LdapErr: DSID-0C0903A9, comentário: erro AcceptSecurityContext, dados 533, v1db1

Ao executar ldbsearch -H /var/lib/samba/private/sam.ldb '(cn=testuser)' unicodePwdno samba AD DC, recebo o seguinte:

# record 1
dn: CN=testuser,CN=Users,DC=ldap,DC=test,DC=dev
unicodePwd:: 0pQq91kmGPJQOuQ3oiHPgg==

[...]

(Pergunta secundária, 0pQq91kmGPJQOuQ3oiHPgg==não é igual ao que eu passei, IgBwAHcAMQAyADMANAAhACIAnão faço ideia do porquê. Porém, parece não relacionado.)

Porém, quando uso a smbpasswdferramenta e defino a mesma senha, parece funcionar:

smbpasswd testuser

Posso confirmar isso executando novamente ldbsearch -H /var/lib/samba/private/sam.ldb '(cn=testuser)' unicodePwde recebendo o mesmo registro de volta.

Desta vez, o mesmo script bash funciona:

ldapwhoami -vvv -H ldaps://127.0.0.1:636 -D "CN=testuser,CN=Users,DC=ldap,DC=test,DC=dev" -x -w pw1234\!
ldap_initialize( ldaps://127.0.0.1:636/??base )
u:DEV-AD\testUser
Result: Success (0)

Por que uma mensagem LDAP simples não funciona (que está totalmente de acordo com as unicodePwdespecificações do Active Directory)? O smbpasswd também atualiza algo que é usado na autenticação via ldapsearch -D -wou .net LdapConnection?

Estou tentando executar um arquivo .ldif personalizado no início da inicialização do servidor OpenLDAP e consegui usando o seguinte comando:

ldapadd -x -D cn=admin,dc=vlad,dc=lan -w admin -H ldap:// -f ldap/ldap-test.ldif

Infelizmente, quero poder adicionar atributos personalizados e classes de objetos ao esquema usando o seguinte:

dn: cn=schema,cn=config
changetype: modify
add: olcObjectClasses
olcObjectClasses: ( 1.2.3.4.5.6.7.8.9.0 NAME 'myCustomObjectClass'
  DESC 'My Custom Object Class'
  AUXILIARY
  MAY ( customAttribute1 $ customAttribute2 $ customAttribute3 $
        customAttribute4 $ customAttribute5 $ customAttribute6 $
        customAttribute7 $ customAttribute8 $ customAttribute9 $
        customAttribute10 $ customAttribute11 $ customAttribute12 $
        customAttribute13 $ customAttribute14 $ customAttribute15 ) )

Infelizmente, isso gera o erro de acesso insuficiente 50. Esta é a saída de slapcat -n0

dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=extern
 al,cn=auth manage by * break
olcRootDN: cn=admin,cn=config
structuralObjectClass: olcDatabaseConfig
entryUUID: 3e49b716-55fd-103e-8582-a14a85261557
creatorsName: cn=config
createTimestamp: 20240202095739Z
olcRootPW:: e1NTSEF9d3J4NGVYaUFvaGRmc2dDOXlqT0V0cEFmSWhZYklxWXo=
entryCSN: 20240202095739.321947Z#000000#000#000000
modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
modifyTimestamp: 20240202095739Z

dn: olcDatabase={1}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {1}mdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=vlad,dc=lan
olcLastMod: TRUE
olcRootDN: cn=admin,dc=vlad,dc=lan
olcRootPW:: -----
olcDbCheckpoint: 512 30
olcDbMaxSize: 1073741824
structuralObjectClass: olcMdbConfig
entryUUID: 3e49fae6-55fd-103e-8589-a14a85261557
creatorsName: cn=admin,cn=config
createTimestamp: 20240202095739Z
olcDbIndex: uid eq
olcDbIndex: mail eq
olcDbIndex: memberOf eq
olcDbIndex: entryCSN eq
olcDbIndex: entryUUID eq
olcDbIndex: objectClass eq
olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=extern
 al,cn=auth manage by * break
olcAccess: {1}to attrs=userPassword,shadowLastChange by self write by dn="cn
 =admin,dc=vlad,dc=lan" write by anonymous auth by * none
olcAccess: {2}to * by self read by dn="cn=admin,dc=vlad,dc=lan" wri
 te by dn="cn=user-ro,dc=vlad,dc=lan" read by * none
entryCSN: 20240202095739.438344Z#000000#000#000000
modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
modifyTimestamp: 20240202095739Z

Como posso executar o comando acima usando ldapadd ou ldapmodify? Qual usuário é necessário para autenticação.

ATUALIZAR: dn: cn=schema,cn=config changetype: modify add: olcObjectClasses olcObjectClasses: ( 1.2.3.4.5.6.7.8.9.0 NAME 'myCustomObjectClass' DESC 'My Custom Object Class' AUXILIARY MAY ( name ) )

Usado o código acima com o comando: ldapmodify -Y EXTERNAL -H ldapi:// -f ldap/ldap-modify.ldif

Tudo parece bem, deve ser adicionado.

Tentei usar a classe:

dn: OU=CustomOU,DC=vlad,DC=lan
ou: CustomOU
objectClass: top
objectClass: organizationalUnit
objectClass: myCustomObjectClass

Com o comando e diz:

ldapadd -x -D cn=admin,dc=vlad,dc=lan -w admin -H ldap:// -f ldap/ldap-test.ldif 

additional info: objectClass: value #2 invalid per syntax

E ao verificar o slapcat -n0, não parece que o objeto personalizado foi adicionado.

Estou configurando um LDAP (LLDAP, para mesmo logon) e entendo que todo diretório precisa de um DN base. Entendo que o DN Base funciona como um namespace contendo todas as entradas deste diretório. Parece que alterar o DN base de uma configuração LDAP em execução pode não ser trivial.

Então, como devo escolher o DN Base? É completamente arbitrário ou certos requisitos podem surgir em algum momento?

Caso contrário, deveria ser um domínio de minha propriedade ou um namespace DNS reservado/privado? Deveria ter dois componentes CC?

Um requisito que descobri até agora é que, para alguns aplicativos, o DN base pode não estar vazio.

Eu tenho uma configuração Postfix/Dovecot e uso OpenLDAP como back-end de usuário/senha. Os usuários devem fazer login com seu endereço de e-mail totalmente qualificado como nome de usuário devido à hospedagem virtual e, portanto, a parte do domínio é necessária para autenticação, ou seja, os nomes de usuário têm a aparência <local-part>@<fqdn-domain>.

No entanto, existem ataques constantes que tentam autenticar com nomes de usuário sem parte de domínio. Como isso leva a um DN inválido dentro da consulta LDAP, meus logs recebem muitas mensagens de erro devido a um DN LDAP inválido.

Existe alguma opção de configuração que permita ao Dovecot impor algumas verificações de sintaxe iniciais no nome de usuário fornecido e, se isso falhar, o Dovecot abrevia o processo de autenticação com uma resposta de negação imediata em vez de consultar o servidor LDAP e depois falhar?

A configuração LDAP no Dovecot é

uris = ldapi://%2frun%2fopenldap%2fslapd.sock
auth_bind = yes
auth_bind_userdn = uid=%n,ou=users,o=%d,dc=my-host,dc=my-domain,dc=my-tld
base = ou=users,o=%d,dc=server,dc=my-host,dc=my-domain,dc=my-tld

Como você pode ver, minha configuração LDAP usa os chamados "pontos de junção" para fornecer diferentes sub-ramos no DIT para os diferentes domínios hospedados. (A o=%d-parte no DN.) De acordo com o Manual de configuração do Dovecot - Variáveis ​​do usuário , %destará vazio se o nome de usuário não tiver nenhuma parte do domínio após o @.

Quando um invasor tenta se autenticar com um nome de usuário incompleto, isso leva a mensagens de erro supérfluas em meus registros, como

Dec 26 16:25:54 server dovecot[24946]: auth: Error: ldap(root,187.205.80.184): ldap_bind() failed: Invalid DN syntax

Aqui, um invasor de 187.205.80.184 tentou se autenticar como usuário roote o Dovecot tentou procurar, uid=root,ou=users,o=,dc=my-host,dc=my-domain,dc=my-tldo que obviamente é inválido, porque não há nada depois o=.