Emmanuel Garette
2021-Nov-18 15:31 UTC
[Samba] Cannot anymore add an objectclass inetorgperson for an existing user
Hi, With Samba 4.11, I used to create my user with samba-tool and add the objectclass inetorgperson with a LDIF file. I updated Samba to version 4.13.14 and I get a strange error: "objectclass: not permitted to change the structural objectClass on CN=xxxx [user] => [inetOrgPerson]!" I don't want change structural objectClass, just add a new one (which is a subClassOf "user" structural objectclass). I think this is a bug, isn't it? Regards,
Andrew Bartlett
2021-Nov-22 04:34 UTC
[Samba] [NOV 21 Security patch] Explaining why we stopped allowing change of objectclass to inetorgperson for an existing user
On Thu, 2021-11-18 at 16:31 +0100, Emmanuel Garette via samba wrote:> Hi, > > With Samba 4.11, I used to create my user with samba-tool and add > the > objectclass inetorgperson with a LDIF file. > > I updated Samba to version 4.13.14 and I get a strange error: > > "objectclass: not permitted to change the structural objectClass on > CN=xxxx [user] => [inetOrgPerson]!" > > I don't want change structural objectClass, just add a new one (which > is > a subClassOf "user" structural objectclass). > > I think this is a bug, isn't it? > > Regards,Thanks Emmanuel, I'm sorry we didn't call this behaviour out more clearly in the security advisory for CVE-2020-25722. Sadly yes, just as "computer" and "user" are a different structural objectclass, and need to be kept seperate (we often see the right to delegate computers given, but not users, and vice-versa), so is inetOrgPerson (objectclass category 1) We now restrict computer objects to having a trailing $ and a userAccountControl of UF_WORKSTATION_TRUST_ACCOUNT or UF_SERVER_TRUST_ACCOUNT. This would all be meaningless if the objectclass could later change. However more importantly, as we noted in the patch:> CVE-2020-25722 Ensure the structural objectclass > cannot be changed > > If the structural objectclass is allowed to change, then the > restrictions > locking an object to remaining a user or computer will not be > enforcable. > > Likewise other LDAP inheritance rules, which allow only certain > child objects can be bypassed, which can in turn allow creation of > (unprivileged) users where only DNS objects were expected. > > BUG: https://bugzilla.samba.org/show_bug.cgi?id=14753 > BUG: https://bugzilla.samba.org/show_bug.cgi?id=14889 > > Signed-off-by: Andrew Bartlett <abartlet at samba.org> > Reviewed-by: Joseph Sutton <josephsutton at catalyst.net.nz>This ended up being the key part of what made the recent security issues "bad if you delegate the creation of users" to really bad for everyone. I'm sorry this cut across your use case, you will need to build the user from scratch as an inetOrgPerson at the start (eg using LDIF). For everyone else, if you haven't patched your Samba, patch now! Sorry, Andrew Bartlett -- Andrew Bartlett (he/him) https://samba.org/~abartlet/ Samba Team Member (since 2001) https://samba.org Samba Team Lead, Catalyst IT https://catalyst.net.nz/services/samba Samba Development and Support, Catalyst IT - Expert Open Source Solutions