[Samba] Delegation of control failure for any built-in Security Principals

[Rowland Penny]

On 22/01/2023 17:56, Sorin P. wrote:
> Yes I know that (Krb + SSH), but in this case, the keys are not for use 
> by the SSH servers.
> They're used by the git server software which is able to retrieve them 
> automatically from the "sshPublicKey" attribute in AD, and to populate 
> the corresponding field for the user profile existent on the Git server.
> 
> But in order to do that, the users should be able to populate the field 
> with their own public key, using a simple Python script which writes it 
> there.
> https://github.com/LasLabs/active-directory-tools/blob/master/ssh-keyman/ssh-keyman.py <https://github.com/LasLabs/active-directory-tools/blob/master/ssh-keyman/ssh-keyman.py>
> 
> Without delegating access through 'SELF', the users are not able to 
> write the key value, and the script dies with this error:
> {'msgtype': 103, 'msgid': 4, 'result': 50, 'desc': 'Insufficient 
> access', 'ctrls': [], 'info': '00002098: Object 
> CN=Username,CN=Users,DC=domain,DC=org has no write property access\n'}
> 
> The schema was populated using these two LDIF files:
> 
> ssh_class.ldif
> ------------------------------------------------------------------------------------------------------------------------------
> dn: CN=ldapPublicKey,CN=Schema,CN=Configuration,DC=domain,DC=org
> changetype: add
> objectClass: top
> objectClass: classSchema
> governsID: 1.3.6.1.4.1.24552.500.1.1.2.0
> cn: ldapPublicKey
> name: ldapPublicKey
> description: MANDATORY: OpenSSH LPK objectclass
> lDAPDisplayName: ldapPublicKey
> subClassOf: top
> objectClassCategory: 3
> objectCategory: CN=Class-Schema,CN=Schema,CN=Configuration,DC=domain,DC=org
> defaultObjectCategory: 
> CN=ldapPublicKey,CN=Schema,CN=Configuration,DC=domain,DC=org
> mayContain: sshPublicKey
> schemaIDGUID:: +8nFQ43rpkWTOgbCCcSkqA==
> 
> 
> ssh_class.ldiff
> ------------------------------------------------------------------------------------------------------------------------------
> dn: CN=sshPublicKey,CN=Schema,CN=Configuration,DC=domain,DC=org
> changetype: add
> objectClass: top
> objectClass: attributeSchema
> attributeID: 1.3.6.1.4.1.24552.500.1.1.1.13
> cn: sshPublicKey
> name: sshPublicKey
> lDAPDisplayName: sshPublicKey
> description: MANDATORY: OpenSSH Public key
> attributeSyntax: 2.5.5.10
> oMSyntax: 4
> isSingleValued: FALSE
> objectCategory: 
> CN=Attribute-Schema,CN=Schema,CN=Configuration,DC=domain,DC=org
> searchFlags: 8
> schemaIDGUID:: cjDAZyEXzU+/akI0EGDW+g==
> 
> 
> How can I overcome this problem? I really need to allow users to write 
> their own sshPublicKey attribute.

The problem is, they should be able to write to their own AD object.

As far as I can see from a short scan of the script, there is a config 
script holding the URI, BASE_DN, ssh_key_attr and the ldap server to 
use. It then prompts for the username and password

It then uses this data to find the users object and then replaces the 
key, which, if it is doing this as the user, should happen.

Rowland