Login problem with Windows 7 local profile and Samba as an NT4-style domain controller

English Network/Internet
1

Hi,

I’m having some issues with Samba and Windows 7 and would very much appreciate some help on this :slight_smile:

When trying to login on a Windows 7 machine I get the following error:
“There are currently no logon servers available to service the logon”.

I get this error most of the time, but occasionally I’m actually able to login when trying
multiple times and rebooting the client machine. Additionally, this problem only seems to happen
on some of the machines when trying to login with the same user (using a local profile on each machine).
This would suggest that the server configuration is not completely messed up?
I was able to join all these machines to the domain without a problem.

Also, when able to login to Windows, I can use the samba shares without any problems.

A related problem is that on none of the machines I’m able to login without a network
connection using a local profile (that is, caching of credentials doesn’t seem to work).
Does anybody have an idea how to fix this
(I understand that solving this should also solve the problem mentioned above)?

Previously I also had the problem of Windows using only temporary profiles on these same machines,
but this I was able to fix by setting logon path to empty string in smb.conf.

I’ve done these registry changes to Windows clients:
https://wiki.samba.org/index.php/Registry_changes_for_NT4-style_domains

I’ve also added the Samba server to the Windows lmhosts-file, disabled IPv6 on client, tried to increase
the number of logins that Windows caches to 50 and enforced Windows not to wait for the network on a login using gpedit.msc.

I’m using OpenSUSE 13.1 and Samba 4.1.6-3.18.1-3208-SUSE-oS13.1-x86-64

Here’s the relevant part of my smb.conf file. I’m really not a Samba or a Windows networking expert
so there really might be something basic wrong here… Any help is greatly apprecieated!



[global]
    workgroup = MYDOMAIN
    passdb backend = tdbsam
    printing = cups
    printcap name = cups
    printcap cache time = 750
    cups options = raw
    map to guest = Bad User
    logon path =  
    logon home = \\%L\%U\.9xprofile
    logon drive = P:
    usershare allow guests = No
    add machine script = /usr/sbin/useradd  -c Machine -d /var/lib/nobody -s /bin/false %m$
    domain logons = Yes
    domain master = Yes
    local master = Yes
    netbios name = myname
    os level = 65
    preferred master = Yes
    security = user
    wins support = Yes
[homes]
    comment = Home Directories
    valid users = %S, %D%w%S
    browseable = No
    read only = No
    inherit acls = Yes
[profiles]
    comment = Network Profiles Service
    path = %H
    read only = No
    store dos attributes = Yes
    create mask = 0600
    directory mask = 0700
[users]
    comment = All users
    path = /home
    read only = No
    inherit acls = Yes
    veto files = /aquota.user/groups/shares/
[groups]
    comment = All groups
    path = /home/groups
    read only = No
    inherit acls = Yes
[printers]
    comment = All Printers
    path = /var/tmp
    printable = Yes
    create mask = 0600
    browseable = No
[print$]
    comment = Printer Drivers
    path = /var/lib/samba/drivers
    write list = @ntadmin root
    force group = ntadmin
    create mask = 0664
    directory mask = 0775    
[netlogon]
    comment = Network Logon Service
    path = /var/lib/samba/netlogon
    write list = root
2

Hi japa and Welcome to the openSUSE community forum!

Hi,

I’m having some issues with Samba and Windows 7 and would very much appreciate some help on this :slight_smile:

When trying to login on a Windows 7 machine I get the following error:
“There are currently no logon servers available to service the logon”.

The error suggests that the domain controller couldn’t be found by Windows when querying the network. When you use a NT4 domain controller, the domain controller is found using NetBIOS browsing. Is NetBIOS browsing allowed through the firewalls of the Windows 7 workstations? I already have issues with domain logon because of firewalls which suddenly block everything after a Windows/Microsoft update.

I get this error most of the time, but occasionally I’m actually able to login when trying
multiple times and rebooting the client machine. Additionally, this problem only seems to happen
on some of the machines when trying to login with the same user (using a local profile on each machine).
This would suggest that the server configuration is not completely messed up?
I was able to join all these machines to the domain without a problem.

Also, when able to login to Windows, I can use the samba shares without any problems.

So Samba authentication isn’t the problem.

A related problem is that on none of the machines I’m able to login without a network
connection using a local profile (that is, caching of credentials doesn’t seem to work).
Does anybody have an idea how to fix this
(I understand that solving this should also solve the problem mentioned above)?

I’m not sure how this problem can be related to the error “There are currently no logon servers available to service the logon”. If you already logged in on a WIndows 7 workstation, caching credentials should work.

Previously I also had the problem of Windows using only temporary profiles on these same machines,
but this I was able to fix by setting logon path to empty string in smb.conf.

I’ve done these registry changes to Windows clients:
https://wiki.samba.org/index.php/Registry_changes_for_NT4-style_domains

I’ve also added the Samba server to the Windows lmhosts-file, disabled IPv6 on client, tried to increase
the number of logins that Windows caches to 50 and enforced Windows not to wait for the network on a login using gpedit.msc.

I’m not a Windows expert, but I think you should configure your Windows workstations so they wait for the network on login so they can find the domain controler.

I’m using OpenSUSE 13.1 and Samba 4.1.6-3.18.1-3208-SUSE-oS13.1-x86-64

Here’s the relevant part of my smb.conf file. I’m really not a Samba or a Windows networking expert
so there really might be something basic wrong here… Any help is greatly apprecieated!

…]

I see nothing wrong with your smb.conf file.

Let’s first check that your domain controller is advertised correctly on your network. On your domain controller, please execute the following command line and share with us the ouput:


$ nmblookup 'MYDOMAIN#1b' 'MYDOMAIN#1c'

This will list the IP address of the domain master (<0x1b>) and the domain controlers (<0x1c>) of the MYDOMAIN domain. If your Samba domain controller is advertised correctly, you sould see its IP address.

The next step is to check the same thing but on the client side. From a Windows 7 workstation having the issue you described, please execute and share with us the ouput the following command line:


C:\> nbtstat -a myname

This will list the NetBIOS resources registered by the computer with the NetBIOS name myname.

3

Kaiten’s post is correct but I would recommend a few different things to look at.

Understanding the fundamental problem is likely “finding” the DC, you then need to look at how you’re set up.

Although a NetBIOS (WINS) nameserver isn’t required, it’s highly recommended for reliable name resolution. You need to understand that NetBIOS Name Resolution is not the same as Hostname resolution, unless special fallback configurations exist as necessary you need to provide this parallel name resolution service.

So, the typical steps

  • Deploy a NetBIOS Name Server
  • Be sure that DHCP is configuring client machines in the network to <know> that NetBIOS Nameservers exist and what are their IP addresses.

Another good alternative to deploying a NetBIOS Nameserver is to insert the network’s NetBIOS names mapped to IP addresses in a LMhosts file on each machine, this works the same as the more commonly discussed Hosts file. If you don’t want to run around configuring this file on every machine in your network, you can configure DHCP to push a custom LMhosts file to every client.

The worst solution because it’s unreliable and probably what you are doing is to just ignore configuring a reliable NetBIOS name resolution solution. In that case, you’d have to open the NetBIOS Nameserver broadcast port on every machine and rely on broadcasts. In this case your solution is no better than a Workgroup and one of the main reason why people deploy Domain based network security instead of Workgroups.

HTH,
TSU

4

OK, I was finally able to fix this.

For some reason the user had MYSAMBASERVER instead of MYDOMAIN as their domain, as was evident by running pdbedit -L -v .

After realising this the fix was embarrasingly simple: just removing the samba user and adding him again with smbpasswd -x and smbpasswd -a (and making sure the settings/files are copied to the new local profiles).

Now it all seems to work fine, credentials cache and everything.

What I still don’t understand is why the user was able to login consistently on one of the machines and occasionally on two of the other machines. I would expect the user not to be able login to the domain at all unless the user belongs to that domain (the machine accounts however belonged to the domain also according to pdbedit -L -v). This led me to thinking that the problem would have to be something computer/samba-related rather than user related. (There were also other users with similar problems but it turned out these too had a similar problem). Being mislead by these facts - and especially being such a newbie in samba/networking - it just took me way too much time to realise to check this.

Thanks kalten and tsu2 for you replies. And most importantly apologies to you and to anyone else who put effort to this for missing such a basic fix.

5

Cached credentials (ones that worked at least once) can continue to permit authentication if not properly expired.

This is because cached credentials are utilized when the Authenticator can’t be reached. Or, poorly written software can permit locally cached authentication if normal authentication denies, it’s the difference between returning a proper “deny” or responding with a null for instance.

Glad you found your solution, they sometimes are the most simply overlooked or mis-configured.

TSU