samba - Jan 2023 - Delegation of control failure for any built-in Security Principals

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

On 22/01/2023 19:39, Sorin P. wrote:
> 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/
<https://blog.laslabs.com/2017/04/managing-ssh-keys-stored-in-active-directory/>
> 
Just had another thought, because of the date at the top of the script, 
it could well be a python2 script, could it just want upgrading to python3 ?

Rowland