Can anyone help - this is driving me up the wall.
I keep getting this error from my LDAP enabled BDC :
[2004/08/16 15:38:12, 0] rpc_server/srv_netlog_nt.c:get_md4pw(218)
get_md4pw: Workstation ALDEBURGH$: no account in domain
It is the same for all workstations. I have made sure the Sign Or Seal
reg hack is in place. The same client system is OK when not using LDAP
as a password backend.
I have checked the LDAP log output (all 61 pages) and believe there is
nothing abnormal in the output.
User authorisation against LDAP works fine, group mapping is OK.
My latest change is to alter the case in LDAP to uppercase but this has
had no effect.
Here's the output from LDAP for the account above :
dn: uid=aldeburgh$,ou=Computers,dc=adastral,dc=ucl,dc=ac,dc=uk
uidNumber: 5022
sambaDomainName: ADASTRAL
sambaAcctFlags: [W ]
homeDirectory: /dev/null
objectClass: top
objectClass: sambaSamAccount
objectClass: posixAccount
objectClass: account
gidNumber: 251
loginShell: /bin/false
sambaPwdLastSet: 0
sambaLogonTime: 0
sambaLogoffTime: 2147483647
sambaKickoffTime: 2147483647
sambaPwdCanChange: 0
sambaPwdMustChange: 2147483647
description: Computer Account
sambaLMPassword: xxx
sambaNTPassword: xxx
sambaPrimaryGroupSID: S-1-5-21-946251905-4084600911-3774255997-1503
sambaSID: S-1-5-21-946251905-4084600911-3774255997-11044
cn: ALDEBURGH$
displayName: ALDEBURGH$
uid: ALDEBURGH$
Heres the global section of the smb.conf :
netbios name = BURY
log file = /var/log/samba/%m.log
load printers = yes
#LDAP
passdb backend = ldapsam:ldap://ldap.adastral.ucl.ac.uk
passwd chat = *New*password* %n\n *Retype*new*password* %n\n
*passwd:*all*authentication*tokens*updated*successfully*
ldap delete dn = Yes
add user script = /usr/local/sbin/smbldap-useradd -m "%u"
add machine script = /usr/local/sbin/smbldap-useradd -w "%u"
add group script = /usr/local/sbin/smbldap-groupadd -p "%g"
add user to group script = /usr/local/sbin/smbldap-groupmod -m
"%u" "%g"
delete user from group script = /usr/local/sbin/smbldap-groupmod
-x "%u" "%g"
set primary group script = /usr/local/sbin/smbldap-usermod -g
"%g" "%u"
delete user script = /usr/local/sbin/smbldap-userdel "%u"
delete group script = /usr/local/sbin/smbldap-groupdel "%g"
ldap admin dn = cn=xxxxxx,dc=adastral,dc=ucl,dc=ac,dc=uk
ldap suffix = dc=adastral,dc=ucl,dc=ac,dc=uk
ldap group suffix = ou=Group
ldap user suffix = ou=People
ldap machine suffix = ou=Computers
ldap idmap suffix = ou=Idmap
ldap ssl = start tls
ldap passwd sync = yes
#LDAP END
logon drive = H:
logon home = \\%L\%U
logon path = \\%L\%U\profile
logon script = common.bat
obey pam restrictions = yes
pam password change = yes
socket options = TCP_NODELAY SO_SNDBUF=8192 SO_RCVBUF=8192
domain master = no
domain logons = yes
encrypt passwords = yes
passwd program = /usr/sbin/smbldap-passwd %u
case sensitive = yes
wins support = yes
dns proxy = no
writeable = yes
server string = Adastral Park BDC Samba Server
printing = cups
preferred master = Yes
workgroup = adastral
time server = yes
os level = 33
printcap name = /etc/printcap
# security = user
Anybody got any clues ?
Thanks,
Neil.
--
Neil Marjoram.
Systems Manager
University College London
Adastral Park Campus
Martlesham Heath
Ipswich
Suffolk
IP5 3RL
01473 663711
>It is the same for all workstations. I have made sure the Sign Or Seal >reg hack is in place. The same client system is OK when not using LDAP >as a password backend. > ><sigh> Should not be needed in Samba 3.>I have checked the LDAP log output (all 61 pages) and believe there is >nothing abnormal in the output. > >User authorisation against LDAP works fine, group mapping is OK. > >My latest change is to alter the case in LDAP to uppercase but this has >had no effect. > >Here's the output from LDAP for the account above : > >dn: uid=aldeburgh$,ou=Computers,dc=adastral,dc=ucl,dc=ac,dc=uk > ><sigh again> Move your computer accounts into ou=People.> ldap machine suffix = ou=Computers > ><sigh 3x> Make this ou=People -- Paul Gienger Office: 701-281-1884 Applied Engineering Inc. Information Systems Consultant Fax: 701-281-1322 URL: www.ae-solutions.com mailto: pgienger@ae-solutions.com
Neil Marjoram a ?crit :>Can anyone help - this is driving me up the wall. > >I keep getting this error from my LDAP enabled BDC : > >[2004/08/16 15:38:12, 0] rpc_server/srv_netlog_nt.c:get_md4pw(218) > get_md4pw: Workstation ALDEBURGH$: no account in domain > > > >I had the same problem and the only solution I found is to have workstation account in same OU than users... Regards, -- Lionel Beard
Neil Marjoram a ?crit :>Can anyone help - this is driving me up the wall. > >I keep getting this error from my LDAP enabled BDC : > >[2004/08/16 15:38:12, 0] rpc_server/srv_netlog_nt.c:get_md4pw(218) > get_md4pw: Workstation ALDEBURGH$: no account in domain > > > >I had the same problem and the only solution I found is to have workstation account in same OU than users... Regards, -- Lionel Beard
Andrew Reilly wrote:>>Maybe so, but this also incurs the extra overhead of searching the >>entire DIT for account information. While it is true that you can most >>likely tune your directory server to guard against performacnce issues, >>widening your search scope is a Bad Thing (TM), especially if you store >>much else than posix account information. >> >> > >Would be interested if you have any metrics regarding >load differences on LDAP directories for the two types >of searches. Particularly if they also include the >size of the directory and the number of searches per >second. > >Nope I sure don't, but that still doesn't make it a good idea. In our setup at present, I'm pretty sure that our servers are way overmatched (too much horsepower) for what they are doing, and our DIT isn't anywhere big enough to cause painful searches. I can see where it would very easily get out of hand with a growing environment that is designed badly from the start and then you just can't find a way to migrate it back to sanity without major pain. Or a sloppy admin could put a uid in a bad location and really start to make things messy. For these reasons it is preferrable to do it right the first time, as painful as it may seem on the front end. I'm going to be testing (in the next couple days hopefully) a method of aliasing the People and Computers OUs into one to see if that works better than overly broadening the base search. Since we'll have a few things that check against the users tree, we don't like having the computer accounts in there either, but it would be easy enough to script out that if the last char is $ it should be excluded from any search.>Haven't done any hard performance testing myself, but we >have not noticed a marked performance difference between >the two configurations to date. We reasoned that this >change only needs to be done for unix servers running >samba, rather than all unix servers on the network. As a >result a small sub set of searches are larger, but the >majority of servers work with a reduced number of objects >in the People OU and we have negated the possibility of >those accounts being used for nefarious purposes on the >vast majority of our unix server that do not use samba >but do use NSS LDAP. > >cheers, >andrew > >-- Paul Gienger Office: 701-281-1884 Applied Engineering Inc. Information Systems Consultant Fax: 701-281-1322 URL: www.ae-solutions.com mailto: pgienger@ae-solutions.com