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

[Sorin P.]

Indeed there is a config file (which I forgot to paste initially). Here it is:---------------------------------------------------------
[ADDC]
URI=dc.domain.org
BASE_DN=CN=Users,DC=domain,DC=org
SSH_KEY_ATTR=sshPublicKey
LDAP_SERVER=ldap://dc.domain.org:389
---------------------------------------------------------
But I don't believe there's any problem with it.
Also here's the procedure that needs to be followed in order to allow the self-write rights.
The live page seems not to be available anymore. Initially was available here: 
https://blog.laslabs.com/2017/04/managing-ssh-keys-stored-in-active-directory/
Thank you.
   On Sunday, January 22, 2023 at 09:11:58 PM GMT+2, Rowland Penny via samba <samba at lists.samba.org> wrote:  
 
 

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


-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba