Não é possível modificar o esquema no OpenLDAP usando a configuração em tempo de execução cn = config

Question

Estou com problemas para modificar o esquema de uma instalação do OpenLDAP usando a configuração de tempo de execução (cn = config). O que estou tentando fazer é modificar os atributos existentes e adicionar novos a um esquema personalizado. O erro que estou recebendo ao tentar aplicar as alterações é "nenhum objeto desse tipo" ou "nenhum desses valores". Ao usar o navegador JXplorer, o erro é:

javax.naming.NameNotFoundException: [LDAP: error code 32 - No Such Object]; remaining name 'cn={15}mySchema,cn=schema,cn=config'

Usar ldapmodify em um arquivo ldif da linha de comando gera o mesmo erro:

ldapmodify -h ldap://localhost/cn=config -x -p 389 -D cn=admin,cn=config -W -f modify.ldif
modifying entry "cn={15}mySchema,cn=schema,cn=config"
ldap_modify: No such object (32)

O que é estranho, porém, é que, embora esse erro ocorra, as alterações são confirmadas para a instância atual do serviço slapd. Por exemplo, se eu adicionei novos atributos e modifiquei um objeto para incluir esses atributos, esses atributos estarão disponíveis nas entradas que usam esse objeto. Eu posso prosseguir como se as mudanças funcionassem. Se o serviço slapd for reiniciado, no entanto, as alterações serão revertidas.

Se eu remover o {15} inicial do DN no arquivo ldif ou o prefixo semelhante no valor do atributo, recebo o mesmo erro (embora provavelmente por um motivo diferente):

modifying entry "cn=mySchema,cn=schema,cn=config"
ldap_modify: No such object (32)
        matched DN: cn=schema,cn=config

Além disso, posso modificar as outras entradas de cn = config (por exemplo, olcDatabase = {- 1} frontend, cn = config) sem problemas e as alterações persistem nas reinicializações de serviço. É somente quando tento modificar as entradas em cn = schema, cn = config que o erro ocorre.

O servidor está executando o CentOS 6.2, de 64 bits, usando o OpenLDAP 2.4.23, que foi instalado via yum. Eu tentei vários navegadores (JXplorer, Softerra LDAP Administrator), bem como a linha de comando, todos com os mesmos resultados. O proprietário / grupo do diretório slapd.d é ldap / ldap e não há alteração mesmo quando as permissões dos arquivos de esquema são modificadas para 777. O uso do TLS pela porta 636 (navegador ou linha de comandos) também não tem efeito.

Alguém pode lançar alguma luz sobre isso e explicar o que poderia estar me impedindo de modificar o esquema através de cn = config?

EDIT: Aqui está o conteúdo de modify.ldif:

dn: cn={15}mySchema,cn=schema,cn=config
changetype: modify
add: olcAttributeTypes
olcAttributeTypes: ( 1.3.6.1.4.00000.2.3.14 NAME 'myTest' DESC 'This is only a test' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )

Estamos usando nossa empresa PEN no lugar de 00000, e nenhum outro atributo está usando esse OID. Descobri que adicionar um prefixo numérico ao valor do atributo não faz diferença, mas o prefixo é necessário para o DN; sem isso, o erro significa o que diz e o diretório não é modificado.

    

Answer 1

Se houver outros olcAttributeTypes na entrada, você deverá fazer um replace não add e listar todos os outros atributos já existentes no LDAP.

Tente usar ldapvi para edição, ele fará isso automaticamente.

EDIT: Se isso não funcionar, você precisará parar slapd e editar arquivos em /etc/ldap/slap.d/ manualmente. Isso certamente não é uma solução quando as mudanças são relativamente frequentes ...

O esquema de edição em cn=config é um novo recurso, você pode ter encontrado um bug (possivelmente já corrigido na versão mais recente). Verifique OpenLDAP ChangeLog e tente usar a versão mais recente.

    

Answer 2

Ainda estou vendo esse mesmo comportamento no OpenLDAP no Ubuntu. Eu tenho tentado substituir o certificado SSL na minha instância do OpenLDAP e descobri que as instruções no site wiki do Ubuntu não funcionam:

link

Especificamente, estas instruções:

Create the file certinfo.ldif with the following contents (adjust accordingly, our example assumes we created certs using https://www.cacert.org):

dn: cn=config
changetype: modify
replace: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem
-
replace: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/ldap01_slapd_cert.pem
-
replace: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/ldap01_slapd_key.pem

Use the ldapmodify command to tell slapd about our TLS work via the slapd-config database:

sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f /etc/ssl/certinfo.ldif

(Note que eu mudei os comandos add originais para substituir, mas os comandos add originais não funcionaram em uma nova instalação).

Encontrei uma nota técnica neste site do CentOS:

link

2.2.2.2. Restrictions to Modifying Configuration Entries and Attributes

Certain restrictions apply when modifying server entries and attributes:

The cn=monitor entry and its child entries are read-only and cannot be modified, except to manage ACIs.

If an attribute is added to cn=config, the server ignores it.

If an invalid value is entered for an attribute, the server ignores it.

Because ldapdelete is used for deleting an entire entry, use ldapmodify to remove an attribute from an entry.

Esta nota parece estar dizendo que você não pode adicionar atributos a cn = config com ldapmodify. Eu pensei que a maneira que você modificou cn = config foi com ldapmodify.

Eu vi outros posts que parecem indicar esse estado de coisas. Coloquei uma questão na lista de discussão do OpenLDAP e atualizarei minha postagem com todas as respostas que receber.