search for: drbeach4

>OK, try running this on the Samba/ldap server: >ldapsearch -h 127.0.0.1 -D cn=admin,dc=drbhome,dc=ca -w -b "dc=drbhome,dc=ca" -s sub "(&(objectClass=sambaDomain)(sambaDomainName=DRBHOME))" sambaDomainName >Can you post the result. ldap_bind: Invalid credentials (49) Hm.

Same physical computer, I performed a fresh and much newer o/s installation (slackware to debian). Samba was v3.5x, moved to the newest stable debian version. Backend is ldap. Testparm is fine. Moved old secrets.tdb, etc, to the appropriate new locations (old system disk is both completely backed up as well as still physically available to me, so I have all files from the old server). Ldap is

Hello list - >From my previous post: ++ First, trusts have been lost with the Win7 workstations in the domain. I would like to recover those trusts with no effect to the user accounts on the workstations. All workstations use local profiles. I can log on to the workstations using cached credentials, but any attempt to log on to them with Samba running on the server fails. So, I stop

> So, net getsambasid and net getlocalsid both return the same value, which matches the SID in the backend LDAP database. So, maybe not a SID problem after all. Here's a log snippet from the server after a logon attempt from the workstation in question, with the failed workstation authentication. I'm not sure how to further debug "credentials check failed": [2016/02/28

> Is ldap running on the Samba machine ? Yes, this is the only server in the domain. > Have you set the ldap password with 'smbpasswd -w' Yes, and based on log.smbd Samba can connect . > I would remove this line: server role = standalone server You are not running a standalone server. The parameter is new since the previous version of Samba I was running (v3.5.6), and

So this got me thinking that maybe a chunk of my problem is with LDAP itself on the server. Executing "slapcat" shows me what I believe to be the correct content, including what looks like appropriate content underneath the following: dn: sambaDomainName=DRBHOME,dc=drbhome,dc=ca That seems to answer the question about whether the domain info is actually there. >> Can you also

Hello list - I am not sure my messages are getting out to the list, so I will attempt in this message to summarize the problems I am having that have been the subject of a few other posts. I recently upgraded from a command-line Slackware installation to Debian Jessie. As part of that exercise, Samba was upgraded from 3.5.x to 4.1.17. My upgrade method was probably not idea: I recursively

Suggested changes applied to smb.conf (and yes, server role is classic PDC): server max protocol = NT1 client signing = auto client ipc signing = auto server signing = auto With no apparent change to the behaviour or resolution to the problem(s). I'm particularly mystified by the logging-in behaviour (that is, if I manage to do it quickly I can log in, but if I

I have had a very odd problem for a while now, and am hoping this will ring a bell for someone who can point me in the right direction. I had a previous Samba DC (v3.5.6) in my home network, running on a command-line Slackware box. For a variety of reasons I decided to switch to Debian Jessie, which included an upgrade to Samba 4.2.10. I did NOT properly migrate my samba files to the new

Hello list! I'm trying to debug a problem that surfaced after a Samba upgrade from v3.5.x to v4.1.17. The problem is that Win7 workstations appear to randomly experience domain trust issues logging in, although they can log in some times, they are unsuccessful at other times. I cannot so far predict what would result in or influence this behaviour. These are workstations on which

Because I'm a masochist, I decided to port my previous (and much older) Samba configuration running a (much older) Slackware implementation to a (much) new server (running Debian Jessie) without actually looking at how to migrate it. Great fun, lots of problems to solve now. The problem of the moment: /var/log/samba/log.smbd tells me it cannot find the domain info in the ldap backend.

>> This makes no sense to me. Am I missing something obvious? > You may be, but how can we tell, we cannot see your smb.conf Complete smb.conf below: # Sample configuration file for the Samba suite for Debian GNU/Linux. # # # This is the main Samba configuration file. You should read the # smb.conf(5) manual page in order to understand the options listed # here. Samba has a huge number