Topic: "Failed to add entry for user"

[mdo]

Hi

when trying to add a new user (dgurney) through server-manager onto a SME9.1 server (quite a few updates are not installed yet), we see the following in the logs:

Group dgurney successfully added!
User dgurney successfully added!
User dgurney successfully modified!
Failed to add entry for user dgurney.
Could not lock (smb) password for dgurney
S04user-create-unix=action|Event|user-create|Action|S04user-create-unix|Start|1469480349 819129|End|1469480351 649149|Elapsed|1.83002|Status|65280
 
This server has been changed some weeks ago to be:
db configuration setprop ldap Authentication enabled (more accidentally at that time when my colleagues were trying to allow ldap access from a third part application (ownCloud) running in another VM).

As I understand, such a change is irreversible and ldap should now be the backend for all authentication. There should be NO (?) entries any longer in /etc/passwd and /etc/group after that change (?) - but there is still contents in both files.

If the switch to ldap would have been completed properly at that time, I suspect we should not (?) see any longer the above "S04user-create-unix" event either.

Having doubts about the status of the ldap server, on the other hand, Samba now seems to rely on ldap auth as below from /etc/samba/smb.conf:

passdb backend = ldapsam:ldap://localhost

ldap admin dn = cn=root,dc=xxxxxxx,dc=co,dc=nz
ldap suffix = dc=xxxxx,dc=co,dc=nz
ldap group suffix = ou=Groups
ldap user suffix = ou=Users
ldap machine suffix = ou=Computers
ldap delete dn = no
ldap passwd sync = yes
ldap ssl = off

Windows domain logons are enabled, also Windows user roaming profiles and for all existing users and machine accounts, that is all working. I am scared of breaking this. Not sure what to do. Would appreciate help.

[Daniel B.]

Hi

when trying to add a new user (dgurney) through server-manager onto a SME9.1 server (quite a few updates are not installed yet), we see the following in the logs:

Group dgurney successfully added!
User dgurney successfully added!
User dgurney successfully modified!
Failed to add entry for user dgurney.
Could not lock (smb) password for dgurney
S04user-create-unix=action|Event|user-create|Action|S04user-create-unix|Start|1469480349 819129|End|1469480351 649149|Elapsed|1.83002|Status|65280
 
This server has been changed some weeks ago to be:
db configuration setprop ldap Authentication enabled (more accidentally at that time when my colleagues were trying to allow ldap access from a third part application (ownCloud) running in another VM).

That's indeed a mistake, as you're now running in an experimental mode (and it wasn't needed to auth against LDAP, but now it's done...)

As I understand, such a change is irreversible and ldap should now be the backend for all authentication. There should be NO (?) entries any longer in /etc/passwd and /etc/group after that change (?) - but there is still contents in both files.

No, there will always be entries in /etc/passwd etc... but only for system accounts. All the users you create from the serveur manager should not appear here anymore (same for the groups)

If the switch to ldap would have been completed properly at that time, I suspect we should not (?) see any longer the above "S04user-create-unix" event either.

No, users still need to be created. user-create-unix just create it in LDAP instead of both LDAP and the local database.

You should take a look at /var/log/ldap/current which can contain useful info to understand why the user account has not been created. Anyway, I'd recommend reverting this server back to a working state, before Authentication has been set to enabled. It can be by restoring a backup, or by manually rebuilding the flat files /etc/{passwd,shadow,groups,gpasswd,/etc/samba/smbpasswd}. I've done this once, see https://wikit.firewall-services.com/doku.php/tuto/ipasserelle/divers/supprimer_auth_ldap for some hints on how to do this.

[mdo]

Thank you for your help and sorry for the delay with my response. I will definitely try to go down that path (revert back from ldap) to config files. Have not done this yet.

FTR, suspicious (?) entries from ldap logfile. Not sure whether these are in any way important but cannot find these in our SME server logs.

2016-08-04 16:51:05.433035500 57a2c9b9 conn=11055 op=14 SRCH base="dc=xxxxxxx,dc=co,dc=nz" scope=2 deref=0 filter="(&(objectClass=sambaGroupMapping)(sambaGroupType=4)(|(sambaSIDList=s-1-5-21-1854542735-3909872708-4225337383-11158)(sambaSIDList=s-1-5-21-1854542735-3909872708-4225337383-11159)(sambaSIDList=s-1-5-21-1854542735-3909872708-4225337383-513)(sambaSIDList=s-1-5-21-1854542735-3909872708-4225337383-11005)(sambaSIDList=s-1-5-21-1854542735-3909872708-4225337383-11013)(sambaSIDList=s-1-5-21-1854542735-3909872708-4225337383-11051)(sambaSIDList=s-1-5-21-1854542735-3909872708-4225337383-11063)))"
2016-08-04 16:51:05.433042500 57a2c9b9 conn=11055 op=14 SRCH attr=sambaSID
2016-08-04 16:51:05.433042500 57a2c9b9 <= bdb_equality_candidates: (sambaGroupType) not indexed
2016-08-04 16:51:05.433043500 57a2c9b9 <= bdb_equality_candidates: (sambaSIDList) not indexed
2016-08-04 16:51:05.433043500 57a2c9b9 <= bdb_equality_candidates: (sambaSIDList) not indexed
2016-08-04 16:51:05.433043500 57a2c9b9 <= bdb_equality_candidates: (sambaSIDList) not indexed
2016-08-04 16:51:05.433044500 57a2c9b9 <= bdb_equality_candidates: (sambaSIDList) not indexed
2016-08-04 16:51:05.433045500 57a2c9b9 <= bdb_equality_candidates: (sambaSIDList) not indexed
2016-08-04 16:51:05.433046500 57a2c9b9 <= bdb_equality_candidates: (sambaSIDList) not indexed
2016-08-04 16:51:05.433048500 57a2c9b9 <= bdb_equality_candidates: (sambaSIDList) not indexed