não é possível fazer com que o useradd use LDAP

A interface nsswitch é somente leitura – ela não tem nenhuma operação de adição ou modificação que os módulos de serviço de nomes poderiam fornecer, e todas essas ferramentas realizam modificações diretamente no backend.

Por exemplo, sua useraddferramenta foi escrita especificamente para atualizar o banco de dados de contas locais por meio de /etc/passwd e /etc/shadow e nada mais. (Na verdade, ela vem do pacote 'shadow', que serve apenas para manter os arquivos passwd/shadow/group.)

Você precisará de uma ferramenta diferente para gerenciamento de contas LDAP.¹

¹ (Não conheço nenhum que ainda seria mantido; acabei escrevendo mais ou menos o meu próprio. Um script de shell ldapaddfuncionaria.)

parece que minha implementação não tem um esquema que suporte campos de usuário unix padrão. Por exemplo, quando eu despejo cn=config não há conceito de diretório home ou shell no esquema

Implementações típicas de LDAP são projetadas para ter esquemas configuráveis; o OpenLDAP é fornecido com diversas configurações de esquemas tradicionais em /etc/(open)ldap/schema.

Você está procurando pela posixAccountobjectClass, que – como você já descobriu – está no nisarquivo schema. No entanto, é uma classe auxiliar, e geralmente anexada a um objeto personou inetOrgPerson(do cosineschema neste caso); embora nada impeça você de anexá-la a um deviceobjeto ou a um applicationProcessobjeto. (O último é uma relíquia OSI & X.500, mas é um tanto adequado para representar, por exemplo, um serviço que precisa de sua própria senha LDAP e/ou sua própria conta POSIX.)

Tentei criar um usuário com um arquivo ldif, mas recebo um erro "Nenhum objeto desse tipo (32)". Presumo que isso seja porque a ou que referencio (Pessoas e Grupo) não existe.

Sim, e você terá que criar as entradas "pai" antes de poder colocar qualquer coisa abaixo. Se você acabou de começar com um banco de dados vazio, precisará criar até mesmo a entrada de nível superior correspondente ao sufixo do seu banco de dados (por exemplo, dc=example,dc=orgcomo uma objectClass: domainentrada, ou o=My Little Orgcomo uma organizationentrada). Então crie OUs como organizationalUnitobjetos – embora não seja necessário colocar usuários e grupos sob OUs; não tem problema criá-los sob a entrada de nível superior; eles podem ser movidos para uma OU mais tarde de qualquer maneira.

(Observe que você só precisa adicionar os pais até o sufixo DB – você não precisa adicionar dc=orgneste exemplo.)

Digamos que você tenha uma entrada de banco de dados configurada assim:

dn: olcDatabase={1}mdb,cn=config
objectClass: olcDatabaseConfig
olcSuffix: o=Widgets Corp

Isso significa que você precisaria criar essas entradas (supondo que você queira o tipo típico de hierarquia OU=Usuários):

dn: o=Widgets Corp
objectClass: organization

dn: ou=People,o=Widgets Corp
objectClass: organizationalUnit

dn: cn=Fred Foobar,ou=People,o=Widgets Corp
objectClass: inetOrgPerson
objectClass: posixAccount
cn: Fred Foobar
givenName: Fred
sn: Foobar
uid: fredfoo
uidNumber: 1001
gidNumber: 1000
homeDirectory: /home/fredfoo
[...]

Enquanto que se você tivesse olcSuffix: dc=example,dc=com(estilo AD), você precisaria adicionar:

dn: dc=example,dc=com
objectClass: domain

dn: ou=Users,dc=example,dc=com
objectClass: organizationalUnit

dn: uid=fredfoo,ou=Users,dc=example,dc=com
objectClass: [...]

(Se todos os programas suportam o modelo "vincular como aplicativo, pesquisar, vincular como usuário", então usar dn: cn=ou dn: uid=para o DN da entrada do usuário é uma escolha sua. A maioria dos programas aceita isso, pois é o que o Active Directory faz. Mas se alguns programas suportam apenas o modelo "vincular de acordo uid=%s,ou=Users,etccom um modelo de DN", então você precisará usar uid=.)