samba - Oct 2005 - Problems setting up Samba+LDAP PDC in Debian Sarge

Dear list,

I have been struggling to get working a PDC using Samba with LDAP
backend, in a fresh Debian Sarge install.

1. SeMachineAccountPrivilege

I'm reading IDEALX's Linux Samba-OpenLDAP Howto as guidance.  In my
last attempt, everything appeared to be fine until the very end, the
Integration test, when I added an admin user, got it on the "Domain
Admin" and then tried to grant such group the
SeMachineAccountPrivilege:

dellj81:/# net -U root%MyUnixRootPass rpc rights grant 'CORENA\Domain
Admins' SeMachineAccountPrivilege
Failed to grant privileges for CORENA\Domain Admins
(NT_STATUS_ACCESS_DENIED)

Seems I have some kind of account problem here, since I can't make this
to work using root nor Manager.

The Howto states:

<<To allow workstations to be joined to the domain, a root user must
exist and used (uid=0).

Such a user is created when initializing the directory whith the
smbldap-populate script.

 >From Samba 3.0.12, it is now possible for admin users to join computers
to the domain without using the "root" account."
...
In fact, the 'root' account is needed in the first place so that the
SeXXX privileges can be set.>>

The smbldap-tools didn't setup any root/uid=0 account in LDAP:

dellj81:/# slapcat | grep -i ^uid:
uid: Administrator
uid: nobody
uid: admin
uid: chema
dellj81:/# slapcat | grep -i uidnum
uidNumber: 1004
uidNumber: 998
uidNumber: 999
uidNumber: 1002
uidNumber: 1003

So maybee that's what I'm missing, or should a standard (/etc/passwd)
root suffice?

2. net getlocalsid

Anyway, after fiddling around looking for clues, I found that I no
longer can get my local sid:

[2005/10/25 11:20:25, 0] utils/net.c:net_getlocalsid(494)
  Can't fetch domain SID for name: SERVIDOR1-PDC

So maybee the problem is more deep.  Or there are several problems. =(

net getlocalsid worked when I did setup the smbldap-tools, which is the
last thing I configured, so I don't have an idea of what went wrong
there.

I see on log.nmbd:

[2005/10/25 10:42:15, 0] nmbd/nmbd_logonnames.c:add_logon_names(163)
  add_domain_logon_names:
  Attempting to become logon server for workgroup CORENA on subnet
UNICAST_SUBNET
[2005/10/25 10:42:15, 0]
nmbd/nmbd_become_dmb.c:become_domain_master_browser_wins(327)
  become_domain_master_browser_wins:
  Attempting to become domain master browser on workgroup CORENA,
subnet UNICAST_SUBNET.
[2005/10/25 10:42:15, 0]
nmbd/nmbd_become_dmb.c:become_domain_master_browser_wins(341)
  become_domain_master_browser_wins: querying WINS server from IP
10.9.60.94 <http://10.9.60.94> for domain master browser name
CORENA<1b>
on workgroup
CORENA
[2005/10/25 10:42:15, 0]
nmbd/nmbd_logonnames.c:become_logon_server_success(124)
  become_logon_server_success: Samba is now a logon server for
workgroup CORENA on subnet UNICAST_SUBNET
[2005/10/25 10:42:15, 0]
nmbd/nmbd_become_dmb.c:become_domain_master_stage2(113)
Is this "domain master browser name CORENA<1b>" normal?


3. passwd

I have also found some auth oddities and problems.

When I execute su, I get the Password: promt two times. The first
prompt appears to be ignored, I must only write the password on the
second:

chema@dellj81:~$ su
Password:
Password:

When I try to change root's password, I get this:

dellj81:/home/chema# passwd
passwd: User not known to the underlying authentication module

But I should be able to "passwd" an /etc/passwd user, shouldn't I?

dellj81:/home/chema# id root
uid=0(root) gid=0(root) groups=0(root)

With my normal user, if I try to change the password:

chema@dellj81:~$ ldappasswd
SASL/DIGEST-MD5 authentication started
Please enter your password:
ldap_sasl_interactive_bind_s: Internal (implementation specific) error
(80)
        additional info: SASL(-13): user not found: no secret in
database

This produces the following sldap output:

Oct 25 11:45:03 dellj81 slapd[2925]: SASL [conn=55] Error: unable to
open Berkeley db /etc/sasldb2: No such file or directory
Oct 25 11:45:03 dellj81 last message repeated 2 times
Oct 25 11:45:03 dellj81 slapd[2925]: SASL [conn=55] Failure: no secret
in database
Oct 25 11:45:03 dellj81 slapd[2925]: conn=55 op=2 RESULT tag=97 err=80
text=SASL(-13): user not found: no secret in database

I have yet to enable TLS, so slapd shoulnd't be using SASL, right?

So seems to me I must have several things to fix.  I'll appreciate any
suggestions, log and debug options pointers, and one click solutions.
;-)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chema wrote:
...
| From Samba 3.0.12, it is now possible for admin users
| to join computers to the domain without using
| the "root" account."
| ...
| In fact, the 'root' account is needed in the first place
| so that the SeXXX privileges can be set.>>

Actually, any members of the domain admins group (rid=512)
can assign and revoke privileges.

| Anyway, after fiddling around looking for clues, I
| found that I no longer can get my local sid:
|
| [2005/10/25 11:20:25, 0] utils/net.c:net_getlocalsid(494)
|  Can't fetch domain SID for name: SERVIDOR1-PDC

That would be a pretty big issue, but smbd should regenerate
a random SID on startup.


| chema@dellj81:~$ ldappasswd
| SASL/DIGEST-MD5 authentication started
| Please enter your password:
| ldap_sasl_interactive_bind_s: Internal (implementation
|    specific) error (80)
|    additional info: SASL(-13): user not found: no
|    secret in database
|
| This produces the following sldap output:
....
| I have yet to enable TLS, so slapd shoulnd't be
| using SASL, right?

The StartTLS extended op and and SASL are independent things.








cheers, jerry
====================================================================Alleviating
the pain of Windows(tm)      ------- http://www.samba.org
GnuPG Key                ----- http://www.plainjoe.org/gpg_public.asc
"There's an anonymous coward in all of us."              
--anonymous
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDX3F1IR7qMdg1EfYRAjt6AJ9sIdpo+soLfgq5avrpLmh1uEqGWgCfeXHX
SuLmVP8Ef113COsZL5SrMic=w2N4
-----END PGP SIGNATURE-----

Chema wrote:
> I see on log.nmbd:
> 
> [2005/10/25 10:42:15, 0] nmbd/nmbd_logonnames.c:add_logon_names(163)
>  add_domain_logon_names:
>  Attempting to become logon server for workgroup CORENA on subnet
> UNICAST_SUBNET
> [2005/10/25 10:42:15, 0]
> nmbd/nmbd_become_dmb.c:become_domain_master_browser_wins(327)
>  become_domain_master_browser_wins:
>  Attempting to become domain master browser on workgroup CORENA,
> subnet UNICAST_SUBNET.
> [2005/10/25 10:42:15, 0]
> nmbd/nmbd_become_dmb.c:become_domain_master_browser_wins(341)
>  become_domain_master_browser_wins: querying WINS server from IP
> 10.9.60.94 <http://10.9.60.94> for domain master browser name
CORENA<1b>
> on workgroup
> CORENA
> [2005/10/25 10:42:15, 0]
> nmbd/nmbd_logonnames.c:become_logon_server_success(124)
>  become_logon_server_success: Samba is now a logon server for
> workgroup CORENA on subnet UNICAST_SUBNET
> [2005/10/25 10:42:15, 0]
> nmbd/nmbd_become_dmb.c:become_domain_master_stage2(113)
> Is this "domain master browser name CORENA<1b>" normal?
What make you think those messages have anything to do with the problem
at hand?
> 3. passwd
[snipp]
This is all about pam_ldap/nss_ldap, nothing samba specific.
> 
> With my normal user, if I try to change the password:
> 
> chema@dellj81:~$ ldappasswd
> SASL/DIGEST-MD5 authentication started
> Please enter your password:
> ldap_sasl_interactive_bind_s: Internal (implementation specific) error
> (80)
>        additional info: SASL(-13): user not found: no secret in
> database
> 
> This produces the following sldap output:
> 
> Oct 25 11:45:03 dellj81 slapd[2925]: SASL [conn=55] Error: unable to
> open Berkeley db /etc/sasldb2: No such file or directory
> Oct 25 11:45:03 dellj81 last message repeated 2 times
> Oct 25 11:45:03 dellj81 slapd[2925]: SASL [conn=55] Failure: no secret
> in database
> Oct 25 11:45:03 dellj81 slapd[2925]: conn=55 op=2 RESULT tag=97 err=80
> text=SASL(-13): user not found: no secret in database
> 
> I have yet to enable TLS, so slapd shoulnd't be using SASL, right?
Eh?, you can use ldappasswd -x ... to use simple binds to ldap or setup
/etc/sasl2/slapd.conf to use slapd's internal auxprop plugin and add a
sasl-regexp directive (man slapd.conf) to map SASL id's to DNs.

my /etc/sasl2/slapd.conf (mech_list probably doesn't fit your needs):

#begin
mech_list: GSSAPI DIGEST-MD5 CRAM-MD5 NTLM EXTERNAL
pwcheck_method: auxprop
auxprop_plugin: slapd
#end

cheers
 Paul