smbldap-useradd does strange things. The following line:

smbldap-useradd -a -c "Dr. Lars Hanke" -u 1001 -A -G 100 -N "Hanke" -P -S "Lars" -M mgr mgr

added uid=100 (instead of mgr) and reported that -N is non-numeric. The latter is right, but ;) It did not ask for a password.

smbldap-useradd -a -c "Dr. Lars Hanke" -u 1001 -A -P -M mgr mgr

added mgr finally, complained that -P in non-numeric and neither asked for a password. The exact errors unfortunately are lost due to nano taking over the terminal. The users are created overly correct, however incomplete, in the LDAP. smbldap-usershow reports them as they are created in the LDAP. Even if this issue should be due to misconfiguration, which I currently are not aware of, at least the error messages are strictly misleading then.

As can be seen from the following, the problem can be solved or
by-passed. However, it turns out that the guidance is incomplete, the
option parser is poor, and the in line docs of the configuration give
incorrect advise.  Troubleshooting therefore is tedious trial and error,
requiring knowledge of Perl and LDAP, which should not be assumed as
common. Currently, it is not documented, how smbldap-tools can be used
with passwords, which do not expire.

:~# smbldap-useradd -a -u 1001 -A -N Hanke -S Lars -M mgr mgr
Argument "-N" isn't numeric in numeric ne (!=) at
/usr/sbin/smbldap-useradd line 422.

However created the user uid="Hanke". Next try after deleting the entry:

:~# smbldap-useradd -a  -u 1001 -A -G 100 -N "Hanke" -P -S "Lars" -M mgr mgr
Argument "-G" isn't numeric in numeric ne (!=) at
/usr/sbin/smbldap-useradd line 422.

Created uid=100. Next try after againdeleting the entry:

:~# smbldap-useradd -a -u 1001 -A -P -M mgr mgr
Argument "-P" isn't numeric in numeric ne (!=) at
/usr/sbin/smbldap-useradd line 422.

finally creates user mgr. After, re-reading the man page found that -A
takes a numerical parameter, retry after deleting the ldap entry:

:~# smbldap-useradd -a -c "Dr. Lars Hanke" -u 1001 -A 1 -N Hanke -S Lars
-P -M mgr mgr
failed to add entry: objectClass: value #0 invalid per syntax at
/usr/sbin/smbldap-useradd line 516.

For whatever that means, user mgr exists:

# mgr, Users, Identity.mgr
dn: uid=mgr,ou=Users,dc=Identity,dc=mgr
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
objectClass: sambaSamAccount
cn: Hanke Lars
sn: Lars
givenName: Hanke
uid: mgr
uidNumber: 1001
gidNumber: 10000
homeDirectory: /home/mgr
loginShell: /bin/bash
gecos: Dr. Lars Hanke
userPassword:: e2NyeXB0fXg=
sambaPwdLastSet: 0
sambaLogonTime: 0
sambaLogoffTime: 2147483647
sambaKickoffTime: 2147483647
sambaPwdCanChange: 0
sambaPwdMustChange: 2147483647
displayName: Hanke Lars
sambaAcctFlags: [UX]
sambaSID: S-1-5-21-2225828420-3585340789-1656673187-3002

It does lack the properties added in line 516: sambaPrimaryGroupSID,
sambaLMPassword, sambaNTPassword. Still GQ lists these properties, so
the schema obviously has them. By selectively commenting things out, I
finally found that "misc.schema" should be included for
localMailRecipient. Next try:

:~# smbldap-useradd -a -c "Dr. Lars Hanke" -u 1001 -A 1 -N "Hanke" -S
"Lars" -P -M mgr mgr
Changing UNIX and samba passwords for mgr
New password:
Retype new password:
Use of uninitialized value $config{"defaultMaxPasswordAge"} in string at
/usr/sbin/smbldap-passwd line 277, <STDIN> line 2.
Failed to modify UNIX password: shadowMax: value #0 invalid per syntax
at /usr/sbin/smbldap-passwd line 285, <STDIN> line 2.

The smbldap.conf encourages to comment the "defaultMaxPasswordAge"
option. So it should not lead to this message. It's okay! Worse, the
error in line 285 is due to the same reason. There should be a way to
define passwords, which do not expire.

Hi there,


here I've been also been biten by that issue and patched my
smbldap-passwd as shown in the patch attached.

This issue is also known by the following bug-ID

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505914

and should have been patched by now, isn't it?


Best regards


	t++