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

On 22/01/2023 17:15, Sorin P. wrote:
> Hi Rowland.
> 
> What else can I use instead "SELF" then?
> I'm trying to allow AD users to self-write sshPublicKeys attribute, 
> which I've already added to the schema.
you do realise that properly setup, SSH will work with kerberos, without 
keys or passwords.
> 
> Additionally, the same error appears when choosing "Everyone"
instead
> "SELF".
These Well Know SIDs do not have anything to map them to. If you must 
use keys, then surely the attribute is part of the uses AD object and as 
such should be owned by the user, who should have write permission.

As I said (in a round about way), I use kerberos instead of keys.

Rowland

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

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.
Thanks a lot.Sorin




 

    On Sunday, January 22, 2023 at 07:32:13 PM GMT+2, Rowland Penny via samba
<samba at lists.samba.org> wrote:
 
 

On 22/01/2023 17:15, Sorin P. wrote:
> Hi Rowland.
> 
> What else can I use instead "SELF" then?
> I'm trying to allow AD users to self-write sshPublicKeys attribute, 
> which I've already added to the schema.
you do realise that properly setup, SSH will work with kerberos, without 
keys or passwords.
> 
> Additionally, the same error appears when choosing "Everyone"
instead
> "SELF".
These Well Know SIDs do not have anything to map them to. If you must 
use keys, then surely the attribute is part of the uses AD object and as 
such should be owned by the user, who should have write permission.

As I said (in a round about way), I use kerberos instead of keys.

Rowland


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