[opensuse] smbclient issues
I have two openSUSE machines that have joined the same Windows domain. Both have done this via yast. The 12.3 machine has no trouble verifying users against the domain. The Tumbleweed machine, however, fails. On the openSUSE 12.3 client where it works, I get something like this: smbclient --user=roropq //os12p3/roger WARNING: The "idmap gid" option is deprecated WARNING: The "idmap uid" option is deprecated Unknown parameter encountered: "mangle case" Ignoring unknown parameter "mangle case" Domain=[RAMBOLL] OS=[Unix] Server=[Samba 3.6.12-59.23.1-3256-SUSE-SL12.3-i386] smb: \> On the Tumbleweed machine, I see this: smbclient --user=roropq //Tumblereed/roger WARNING: The "idmap gid" option is deprecated WARNING: The "idmap uid" option is deprecated Unknown parameter encountered: "mangle case" Ignoring unknown parameter "mangle case" Domain=[RAMBOLL] OS=[Windows 6.1] Server=[Samba 4.5.3-0-SUSE-oS13.3-x86_64] tree connect failed: NT_STATUS_ACCESS_DENIED It is interesting that the 12.3 samba reports the OS as Unix, while the Tumbleweed samba reports as Windows 6.1. The Server strings match the installed Samba on each machine. When yast checks that the machine is a member of the domain, it is happy. And the domain admin sees both machine as expected (by him). The two machines, as far as I can tell, have samba configured the exact same way. I see this in the samba logs: [2017/02/09 13:42:51.306927, 0] ../source3/libads/kerberos_util.c:74(ads_kinit_password) kerberos_kinit_password STO-OPQ-SRC$@RAMBOLL.RAMBOLL-GROUP.GLOBAL.NETWORK failed: KDC has no support for encryption type I have googled this, but I cannot say that I have seen anything that makes sense in the context of samba. This is a bit outside my experience. FYI, the configuration for both machines is: [global] workgroup = RAMBOLL passdb backend = tdbsam printing = cups printcap name = cups printcap cache time = 750 cups options = raw map to guest = Bad User include = /etc/samba/dhcp.conf logon path = \\%L\profiles\.msprofile logon home = \\%L\%U\.9xprofile logon drive = P: usershare allow guests = No idmap gid = 10000-20000 idmap uid = 10000-20000 realm = RAMBOLL.RAMBOLL-GROUP.GLOBAL.NETWORK security = ADS template homedir = /home/%D/%U template shell = /bin/bash winbind refresh tickets = yes mangled names = no usershare max shares = 100 Where to start looking? -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Mind the samba versions Roger. Somethings have changed in version 4. By the way, you don't actually need smbclient to act as a client. Cifs is sufficient. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
I do use cifs when I mount shares. In my use case, I am making shares on the openSUSE host available to Windows users. They authenticate with their Windows credentials. Both the Windows and the local smbclient fail authentication on the newer Samba host. Which is why I feel the issue is on the Samba host. I choose to show smbclient with the error so we could eliminate the Windows clients. Samba all by itself cannot authenticate. I suspected that there could be some difference in the newer samba. The joining of the Windows domain and all else was set up by Yast on the new server with the new Samba. When it failed I looked around at the parts I knew about and saw that it had set things up exactly as an older Yast did on the functioning server running an older Samba. So, is it that Yast has missed something in the new Samba server? On Fri, Feb 10, 2017 at 6:37 PM, John Andersen <jsamyth@gmail.com> wrote:
Mind the samba versions Roger. Somethings have changed in version 4.
By the way, you don't actually need smbclient to act as a client. Cifs is sufficient. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On February 12, 2017 11:07:33 PM PST, Roger Oberholtzer <roger.oberholtzer@gmail.com> wrote:
I do use cifs when I mount shares.
In my use case, I am making shares on the openSUSE host available to Windows users. They authenticate with their Windows credentials. Both the Windows and the local smbclient fail authentication on the newer Samba host. Which is why I feel the issue is on the Samba host. I choose to show smbclient with the error so we could eliminate the Windows clients. Samba all by itself cannot authenticate.
I suspected that there could be some difference in the newer samba. The joining of the Windows domain and all else was set up by Yast on the new server with the new Samba. When it failed I looked around at the parts I knew about and saw that it had set things up exactly as an older Yast did on the functioning server running an older Samba.
So, is it that Yast has missed something in the new Samba server?
On Fri, Feb 10, 2017 at 6:37 PM, John Andersen <jsamyth@gmail.com> wrote:
Mind the samba versions Roger. Somethings have changed in version 4.
By the way, you don't actually need smbclient to act as a client. Cifs is sufficient. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
What about smbpasswd ? Are these users all in there? Ports all open ? -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Feb 13, 2017 at 8:14 AM, John Andersen <jsamyth@gmail.com> wrote:
What about smbpasswd ? Are these users all in there? Ports all open ?
I don't think the users should be in smbpasswd. They are not local users. They are users in the Windows AD that the machine has joined. All authentication is in that place. The machine does not run a firewall and has all ports open. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
They did differ in one line: [domain_realm] .ramse.ramboll-group.global.network = RAMSE.RAMBOLL-GROUP.GLOBAL.NETWORK .ramboll.ramboll-group.global.network = RAMBOLL.RAMBOLL-GROUP.GLOBAL.NETWORK The working samba had the line that starts with .ramse. The non-working did not. .ramse is an old domain. It is now .ramboll. I added that line to the new server (a restarted smb and nmb) but it made no difference. I see that there is a reference to a couple of log files: [logging] kdc = FILE:/var/log/krb5/krb5kdc.log admin_server = FILE:/var/log/krb5/kadmind.log default = SYSLOG:NOTICE:DAEMON These files do not exist. The /var/log/krb5 directory is empty. On Mon, Feb 13, 2017 at 9:26 AM, Michael Hirmke <mh@mike.franken.de> wrote:
Hi Roger,
[...]
Where to start looking?
what does /etc/krb5.conf look like on both machines?
-- Roger Oberholtzer
Bye. Michael. -- Michael Hirmke
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hi Roger,
They did differ in one line:
[domain_realm] .ramse.ramboll-group.global.network = RAMSE.RAMBOLL-GROUP.GLOBAL.NETWORK .ramboll.ramboll-group.global.network = RAMBOLL.RAMBOLL-GROUP.GLOBAL.NETWORK
The working samba had the line that starts with .ramse. The non-working did not. .ramse is an old domain. It is now .ramboll.
I added that line to the new server (a restarted smb and nmb) but it made no difference.
no this difference couldn't be the reason for your problem. What about the lines for encryption types? What about the [libdefaults] section? Can you post them, please? As someone else wrote, there are differences (and not only a few) between the two samba and the two kerberos versions on your different systems. A very simple krb5.conf for two different AD *forests* may look like this: ------------------------< snip snip snip >----------------------------- [logging] default = FILE:/var/log/krb5/libs.log kdc = FILE:/var/log/krb5/kdc.log admin_server = FILE:/var/log/krb5/kadmind.log [libdefaults] default_realm = DOMAIN1.DE dns_lookup_realm = true dns_lookup_kdc = true ticket_lifetime = 24h forwardable = yes [realms] DOMAIN1.DE = { kdc = dc1.domain1.de kdc = dc2.domain1.de admin_server = dc1.domain1.de default_domain = domain1.de } DOMAIN2.DE = { kdc = dc1.domain2.de kdc = dc2.domain2.de admin_server = dc1.domain2.de default_domain = domain2.de } [domain_realm] .domain1.de = DOMAIN1.DE domain1.de = DOMAIN1.DE .domain2.de = DOMAIN2.DE domain2.de = DOMAIN2.DE ------------------------< snip snip snip >----------------------------- This works perfectly here with the latest samba and kerberos versions for openSuSE Leap 42.2 and Tumbleweed against an AD with forest and domain functional level set to "Windows Server 2012 R2".
I see that there is a reference to a couple of log files:
[logging] kdc = FILE:/var/log/krb5/krb5kdc.log admin_server = FILE:/var/log/krb5/kadmind.log default = SYSLOG:NOTICE:DAEMON
These files do not exist. The /var/log/krb5 directory is empty.
They are not used for samba's purpose, only if you use a native Kerberos server. What happens, if you run "kinit <someuser>". Do you get a password prompt? And if you enter the password, do you get a ticket (klist)? Bye. Michael. -- Michael Hirmke -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Feb 13, 2017 at 12:48 PM, Michael Hirmke <mh@mike.franken.de> wrote:
Hi Roger,
They did differ in one line:
[domain_realm] .ramse.ramboll-group.global.network = RAMSE.RAMBOLL-GROUP.GLOBAL.NETWORK .ramboll.ramboll-group.global.network = RAMBOLL.RAMBOLL-GROUP.GLOBAL.NETWORK
The working samba had the line that starts with .ramse. The non-working did not. .ramse is an old domain. It is now .ramboll.
I added that line to the new server (a restarted smb and nmb) but it made no difference.
no this difference couldn't be the reason for your problem. What about the lines for encryption types? What about the [libdefaults] section? Can you post them, please?
This is the entire file (as made by Yast): [libdefaults] default_realm = RAMBOLL.RAMBOLL-GROUP.GLOBAL.NETWORK clockskew = 300 # default_realm = EXAMPLE.COM [realms] RAMBOLL.RAMBOLL-GROUP.GLOBAL.NETWORK = { kdc = ramstodc02.ramboll.ramboll-group.global.network default_domain = ramboll.ramboll-group.global.network admin_server = ramstodc02.ramboll.ramboll-group.global.network } RAMSE.RAMBOLL-GROUP.GLOBAL.NETWORK = { kdc = seramstodc04.ramse.ramboll-group.global.network default_domain = ramse.ramboll-group.global.network admin_server = seramstodc04.ramse.ramboll-group.global.network } # EXAMPLE.COM = { # kdc = kerberos.example.com # admin_server = kerberos.example.com # } [logging] kdc = FILE:/var/log/krb5/krb5kdc.log admin_server = FILE:/var/log/krb5/kadmind.log default = SYSLOG:NOTICE:DAEMON [domain_realm] .ramse.ramboll-group.global.network = RAMSE.RAMBOLL-GROUP.GLOBAL.NETWORK .ramboll.ramboll-group.global.network = RAMBOLL.RAMBOLL-GROUP.GLOBAL.NETWORK [appdefaults] pam = { ticket_lifetime = 1d renew_lifetime = 1d forwardable = true proxiable = false minimum_uid = 1 } It seems not to have: [libdefaults] dns_lookup_realm = true dns_lookup_kdc = true ticket_lifetime = 24h forwardable = yes
As someone else wrote, there are differences (and not only a few) between the two samba and the two kerberos versions on your different systems.
A very simple krb5.conf for two different AD *forests* may look like this:
------------------------< snip snip snip >----------------------------- [logging] default = FILE:/var/log/krb5/libs.log kdc = FILE:/var/log/krb5/kdc.log admin_server = FILE:/var/log/krb5/kadmind.log
[libdefaults] default_realm = DOMAIN1.DE dns_lookup_realm = true dns_lookup_kdc = true ticket_lifetime = 24h forwardable = yes
[realms] DOMAIN1.DE = { kdc = dc1.domain1.de kdc = dc2.domain1.de admin_server = dc1.domain1.de default_domain = domain1.de } DOMAIN2.DE = { kdc = dc1.domain2.de kdc = dc2.domain2.de admin_server = dc1.domain2.de default_domain = domain2.de }
[domain_realm] .domain1.de = DOMAIN1.DE domain1.de = DOMAIN1.DE .domain2.de = DOMAIN2.DE domain2.de = DOMAIN2.DE ------------------------< snip snip snip >-----------------------------
This works perfectly here with the latest samba and kerberos versions for openSuSE Leap 42.2 and Tumbleweed against an AD with forest and domain functional level set to "Windows Server 2012 R2".
I see that there is a reference to a couple of log files:
[logging] kdc = FILE:/var/log/krb5/krb5kdc.log admin_server = FILE:/var/log/krb5/kadmind.log default = SYSLOG:NOTICE:DAEMON
These files do not exist. The /var/log/krb5 directory is empty.
They are not used for samba's purpose, only if you use a native Kerberos server.
What happens, if you run "kinit <someuser>". Do you get a password prompt? And if you enter the password, do you get a ticket (klist)?
When I tried a user from the domain, it seems it was ok. There was no complaint: sto-opq-src:~ # kinit roropq Password for roropq@RAMBOLL.RAMBOLL-GROUP.GLOBAL.NETWORK: sto-opq-src:~ # When I tried a non-existent user, I got: sto-opq-src:~ # kinit roger kinit: Client 'roger@RAMBOLL.RAMBOLL-GROUP.GLOBAL.NETWORK' not found in Kerberos database while getting initial credentials sto-opq-src:~ # So if this is a test of the Kerberos part, it seems to be working. smbclient, otoh, made the same complaint (as does Windows about an access error): sto-opq-src:~ # smbclient --user=roropq //localhost/roger WARNING: The "idmap gid" option is deprecated WARNING: The "idmap uid" option is deprecated Domain=[RAMBOLL] OS=[Windows 6.1] Server=[Samba 4.5.3-0-SUSE-oS13.3-x86_64] tree connect failed: NT_STATUS_ACCESS_DENIED sto-opq-src:~ # It I try a share that does not exist, I get: sto-opq-src:~ # smbclient --user=roropq //localhost/rog WARNING: The "idmap gid" option is deprecated WARNING: The "idmap uid" option is deprecated Domain=[RAMBOLL] OS=[Windows 6.1] Server=[Samba 4.5.3-0-SUSE-oS13.3-x86_64] tree connect failed: NT_STATUS_BAD_NETWORK_NAME sto-opq-src:~ # So the share is known on localhost... Does all this imply that kerberos on my machine is ok, but that samba is the problem? -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hi Roger, [...]
This is the entire file (as made by Yast):
[...]
[appdefaults] pam = { ticket_lifetime = 1d renew_lifetime = 1d forwardable = true proxiable = false minimum_uid = 1 }
It seems not to have:
[libdefaults] dns_lookup_realm = true dns_lookup_kdc = true ticket_lifetime = 24h forwardable = yes
most of these have been written to the appdefault section, as it seems. This is ok, I suppose. [...]
What happens, if you run "kinit <someuser>". Do you get a password prompt? And if you enter the password, do you get a ticket (klist)?
When I tried a user from the domain, it seems it was ok. There was no complaint:
sto-opq-src:~ # kinit roropq Password for roropq@RAMBOLL.RAMBOLL-GROUP.GLOBAL.NETWORK: sto-opq-src:~ #
When I tried a non-existent user, I got:
sto-opq-src:~ # kinit roger kinit: Client 'roger@RAMBOLL.RAMBOLL-GROUP.GLOBAL.NETWORK' not found in Kerberos database while getting initial credentials sto-opq-src:~ #
So if this is a test of the Kerberos part, it seems to be working.
Ok. Perfect. So you have to look further on the samba part.
smbclient, otoh, made the same complaint (as does Windows about an access error):
sto-opq-src:~ # smbclient --user=roropq //localhost/roger WARNING: The "idmap gid" option is deprecated WARNING: The "idmap uid" option is deprecated
use winbind uid and gid instead. Here are my settings: ; ===================================================================== ; WinBindD ; --------------------------------------------------------------------- # winbind use default domain = yes winbind uid = 50000-60000 winbind gid = 50000-60000 winbind separator = / winbind nested groups = yes winbind enum groups = yes winbind enum users = yes But this is not the reason for you problems, just cosmetics.
sto-opq-src:~ # smbclient --user=roropq //localhost/roger WARNING: The "idmap gid" option is deprecated WARNING: The "idmap uid" option is deprecated Domain=[RAMBOLL] OS=[Windows 6.1] Server=[Samba 4.5.3-0-SUSE-oS13.3-x86_64] tree connect failed: NT_STATUS_ACCESS_DENIED sto-opq-src:~ #
What if you add the domain to the user name: sto-opq-src:~ # smbclient --user=<domain>/roropq //localhost/roger or sto-opq-src:~ # smbclient --user=<domain>\\roropq //localhost/roger [...]
So the share is known on localhost...
Does all this imply that kerberos on my machine is ok, but that samba is the problem?
Seems so, yes. How does the according section in the smb.conf look like? Something like # Active Directory security = ADS realm = DOMAIN1 password server = <ip server 1> <ip server 2> server max protocol = smb3 where realm and password server have to match the entries in krb5.conf. Can you increase the log level for authentication in the samba config? log level = auth:10 If there is nothing more to see, increase all debug classes: log level = 10 And have a look into the security logs of your domain controllers. Perhaps you can find warnings or error messages regarding the problem there.
-- Roger Oberholtzer
Bye. Michael. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, Feb 14, 2017 at 10:48 AM, Michael Hirmke <mh@mike.franken.de> wrote:
Hi Roger,
# winbind use default domain = yes winbind uid = 50000-60000 winbind gid = 50000-60000 winbind separator = / winbind nested groups = yes winbind enum groups = yes winbind enum users = yes
But this is not the reason for you problems, just cosmetics.
I made the changes. Nice to have the messages gone. Odd that Yast on Tumbleweed puts some of those in the file.
sto-opq-src:~ # smbclient --user=roropq //localhost/roger WARNING: The "idmap gid" option is deprecated WARNING: The "idmap uid" option is deprecated Domain=[RAMBOLL] OS=[Windows 6.1] Server=[Samba 4.5.3-0-SUSE-oS13.3-x86_64] tree connect failed: NT_STATUS_ACCESS_DENIED sto-opq-src:~ #
What if you add the domain to the user name:
sto-opq-src:~ # smbclient --user=<domain>/roropq //localhost/roger or sto-opq-src:~ # smbclient --user=<domain>\\roropq //localhost/roger
[...]
So the share is known on localhost...
I am using localhost when testing on the Tumbleweed machine. But the FQDN has the same failure. Adding the doman to the user name made no difference. sto-opq-src:/etc/samba # smbclient --user=RAMBOLL/roropq //sto-opq-src.scc.se/roger Domain=[RAMBOLL] OS=[Windows 6.1] Server=[Samba 4.5.3-0-SUSE-oS13.3-x86_64] tree connect failed: NT_STATUS_ACCESS_DENIED
How does the according section in the smb.conf look like? Something like
# Active Directory security = ADS realm = DOMAIN1 password server = <ip server 1> <ip server 2> server max protocol = smb3
I only have these: realm = RAMBOLL.RAMBOLL-GROUP.GLOBAL.NETWORK security = ADS I added: password server = ramstodc02.ramboll.ramboll-group.global.network server max protocol = smb3 But it made no difference.
where realm and password server have to match the entries in krb5.conf.
Can you increase the log level for authentication in the samba config? log level = auth:10 If there is nothing more to see, increase all debug classes: log level = 10
This is interesting. I get the following: [2017/02/14 11:31:44.056943, 5, pid=15668, effective(0, 0), real(0, 0), class=auth] ../source3/auth/auth_util.c:122(make_user_info_map) Mapping user [RAMBOLL]\[roropq] from workstation [STO-OPQ-SRC] [2017/02/14 11:31:44.057548, 5, pid=15668, effective(0, 0), real(0, 0), class=auth] ../source3/auth/user_info.c:62(make_user_info) attempting to make a user_info for roropq (roropq) [2017/02/14 11:31:44.057612, 5, pid=15668, effective(0, 0), real(0, 0), class=auth] ../source3/auth/user_info.c:70(make_user_info) making strings for roropq's user_info struct [2017/02/14 11:31:44.057623, 5, pid=15668, effective(0, 0), real(0, 0), class=auth] ../source3/auth/user_info.c:108(make_user_info) making blobs for roropq's user_info struct [2017/02/14 11:31:44.057638, 10, pid=15668, effective(0, 0), real(0, 0), class=auth] ../source3/auth/user_info.c:159(make_user_info) made a user_info for roropq (roropq) [2017/02/14 11:31:44.057647, 3, pid=15668, effective(0, 0), real(0, 0), class=auth] ../source3/auth/auth.c:178(auth_check_ntlm_password) check_ntlm_password: Checking password for unmapped user [RAMBOLL]\[roropq]@[STO-OPQ-SRC] with the new password interface [2017/02/14 11:31:44.057657, 3, pid=15668, effective(0, 0), real(0, 0), class=auth] ../source3/auth/auth.c:181(auth_check_ntlm_password) check_ntlm_password: mapped user is: [RAMBOLL]\[roropq]@[STO-OPQ-SRC] [2017/02/14 11:31:44.057666, 10, pid=15668, effective(0, 0), real(0, 0), class=auth] ../source3/auth/auth.c:190(auth_check_ntlm_password) check_ntlm_password: auth_context challenge created by random [2017/02/14 11:31:44.057675, 10, pid=15668, effective(0, 0), real(0, 0), class=auth] ../source3/auth/auth.c:192(auth_check_ntlm_password) challenge is: [2017/02/14 11:31:44.057684, 10, pid=15668, effective(0, 0), real(0, 0), class=auth] ../source3/auth/auth_builtin.c:41(check_guest_security) Check auth for: [roropq] [2017/02/14 11:31:44.057694, 10, pid=15668, effective(0, 0), real(0, 0), class=auth] ../source3/auth/auth.c:233(auth_check_ntlm_password) check_ntlm_password: guest had nothing to say [2017/02/14 11:31:44.057703, 10, pid=15668, effective(0, 0), real(0, 0), class=auth] ../source3/auth/auth_sam.c:75(auth_samstrict_auth) Check auth for: [roropq] [2017/02/14 11:31:44.057713, 6, pid=15668, effective(0, 0), real(0, 0), class=auth] ../source3/auth/auth_sam.c:88(auth_samstrict_auth) check_samstrict_security: RAMBOLL is not one of my local names (ROLE_DOMAIN_MEMBER) [2017/02/14 11:31:44.057722, 10, pid=15668, effective(0, 0), real(0, 0), class=auth] ../source3/auth/auth.c:233(auth_check_ntlm_password) check_ntlm_password: sam had nothing to say [2017/02/14 11:31:44.057732, 10, pid=15668, effective(0, 0), real(0, 0), class=auth] ../source3/auth/auth_winbind.c:50(check_winbind_security) Check auth for: [roropq] [2017/02/14 11:31:44.065621, 3, pid=15668, effective(0, 0), real(0, 0), class=auth] ../source3/auth/auth_util.c:1233(check_account) Failed to find authenticated user RAMBOLL/roropq via getpwnam(), denying access. [2017/02/14 11:31:44.065684, 5, pid=15668, effective(0, 0), real(0, 0), class=auth] ../source3/auth/auth.c:252(auth_check_ntlm_password) check_ntlm_password: winbind authentication for user [roropq] FAILED with error NT_STATUS_NO_SUCH_USER [2017/02/14 11:31:44.065719, 2, pid=15668, effective(0, 0), real(0, 0), class=auth] ../source3/auth/auth.c:315(auth_check_ntlm_password) check_ntlm_password: Authentication for user [roropq] -> [roropq] FAILED with error NT_STATUS_NO_SUCH_USER [2017/02/14 11:31:44.065730, 3, pid=15668, effective(0, 0), real(0, 0), class=auth] ../source3/auth/auth_util.c:1611(do_map_to_guest_server_info) No such user roropq [RAMBOLL] - using guest account NT_STATUS_NO_SUCH_USER seems unexpected. The user does exist. It is the same one I use from the working Samba! I can't tell if that complaint is really coming from the Domain controller, or something samba has decided locally... -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hi Roger, [...]
NT_STATUS_NO_SUCH_USER seems unexpected. The user does exist. It is the same one I use from the working Samba! I can't tell if that complaint is really coming from the Domain controller, or something samba has decided locally...
sorry, but at that point I'm running out of ideas without checking your complete environment 8-< Did you have a look into the DC's security log? You could try to remove all samba tdb files, rejoin it to the domain and retry accessing the shares. But no guarantee, that it won't even get worse.
-- Roger Oberholtzer
Bye. Michael. -- Michael Hirmke -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, Feb 14, 2017 at 12:57 PM, Michael Hirmke <mh@mike.franken.de> wrote:
Hi Roger,
[...]
NT_STATUS_NO_SUCH_USER seems unexpected. The user does exist. It is the same one I use from the working Samba! I can't tell if that complaint is really coming from the Domain controller, or something samba has decided locally...
sorry, but at that point I'm running out of ideas without checking your complete environment 8-< Did you have a look into the DC's security log?
You could try to remove all samba tdb files, rejoin it to the domain and retry accessing the shares. But no guarantee, that it won't even get worse.
Too bad. It is a hassle to join the domain. They won't let me have the password. I need to file a support ticket and wait. Then someone may pass by ready to enter the key... I guess I will see if they can tell if the DC is even trying to authenticate this user from this machine. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hi Roger, [...]
You could try to remove all samba tdb files, rejoin it to the domain and retry accessing the shares. But no guarantee, that it won't even get worse.
Too bad. It is a hassle to join the domain. They won't let me have the password. I need to file a support ticket and wait. Then someone may pass by ready to enter the key...
oops, you are not an admin?
I guess I will see if they can tell if the DC is even trying to authenticate this user from this machine.
Ok, now i understand your real problem - you never see both sides 8-< For problems like this IMHO this is essential.
-- Roger Oberholtzer
Bye. Michael. -- Michael Hirmke -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, Feb 14, 2017 at 4:54 PM, Michael Hirmke <mh@mike.franken.de> wrote:
oops, you are not an admin?
Nope. The Windows domain is worldwide for our company with over 15000 users. They look at my Linux stuff as mysterious. I just try to make it fit in so the users are none the wiser. Except that it always works.
I guess I will see if they can tell if the DC is even trying to authenticate this user from this machine.
Ok, now i understand your real problem - you never see both sides 8-< For problems like this IMHO this is essential.
I agree. I guess I need to request support help. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, Feb 14, 2017 at 4:54 PM, Michael Hirmke <mh@mike.franken.de> wrote:
Hi Roger,
Ok, now i understand your real problem - you never see both sides 8-< For problems like this IMHO this is essential.
I am curious: if I can authenticate using kinit, what can I then do? Or is that just that a program (samba, apache) can authenticate a user and then, upon success, the program can do something? Or is there something general I may look at? I guess this is just curiosity more than a solution to this problem. I have on my list using the same AD to authenticate some things in apache. That is next on my list. I have requested a log of the access attempts from the machine with a problem. Maybe there will be a clue there. My users are getting restless :) -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hi Roger,
On Tue, Feb 14, 2017 at 4:54 PM, Michael Hirmke <mh@mike.franken.de> wrote:
Hi Roger,
Ok, now i understand your real problem - you never see both sides 8-< For problems like this IMHO this is essential.
I am curious: if I can authenticate using kinit, what can I then do? Or is that just that a program (samba, apache) can authenticate a user and then, upon success, the program can do something? Or is there something general I may look at? I guess this is just curiosity more than a solution to this problem. I have on my list using the same AD to authenticate some things in apache. That is next on my list.
I try to explain, how I understand it - be careful, that might be at least partially incorrect: Kerberos is the authentication method - you get a ticket granting ticket from the kdc, in this case the AD Domain controller. With this ticket you can get a service ticket for accessing a service on a certain machine providing that service, for example a file share. This is the authorization part. In your case the authentication part works, but the authorization part fails.
I have requested a log of the access attempts from the machine with a problem. Maybe there will be a clue there. My users are getting restless :)
Good luck!
-- Roger Oberholtzer
Bye. Michael. -- Michael Hirmke -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
I'm still fighting with this issue. The Windows server seems not to provide a clue. To recap: I have a SAMBA server on an openSUSE Tumbleweed machine. It has joined the corporate Windows AD. I want to authenticate users accessing SAMBA shares in this AD. I can join the corporate AD with kinit. I have the following: # klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: roropq@ZZZ.RAMBOLL-GROUP.GLOBAL.NETWORK Valid starting Expires Service principal 03/07/17 14:16:24 03/08/17 00:16:24 krbtgt/ZZZ.RAMBOLL-GROUP.GLOBAL.NETWORK@ZZZ.RAMBOLL-GROUP.GLOBAL.NETWORK renew until 03/08/17 14:16:20 # net ads info LDAP server: 10.2.5.22 LDAP server name: RAMSTODCZZ.ramboll.ramboll-group.global.network Realm: ZZZ.RAMBOLL-GROUP.GLOBAL.NETWORK Bind Path: dc=ZZZ,dc=RAMBOLL-GROUP,dc=GLOBAL,dc=NETWORK LDAP port: 389 Server time: Tue, 07 Mar 2017 14:30:05 CET KDC server: 10.2.5.22 Server time offset: 0 Last machine account password change: Thu, 02 Mar 2017 13:36:54 CET But I cannot a authenticate against SAMBA (with either smbclient on this or a remote machine, or from a Windows PC wanting to access the SAMBA shares). % smbclient -k -d 10 //ZZZ.RAMBOLL-GROUP.GLOBAL.NETWORK/roropq INFO: Current debug levels: all: 10 tdb: 10 printdrivers: 10 lanman: 10 smb: 10 rpc_parse: 10 rpc_srv: 10 rpc_cli: 10 passdb: 10 sam: 10 auth: 10 winbind: 10 vfs: 10 idmap: 10 quota: 10 acls: 10 locking: 10 msdfs: 10 dmapi: 10 registry: 10 scavenger: 10 dns: 10 ldb: 10 tevent: 10 lp_load_ex: refreshing parameters Initialising global parameters rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384) INFO: Current debug levels: all: 10 tdb: 10 printdrivers: 10 lanman: 10 smb: 10 rpc_parse: 10 rpc_srv: 10 rpc_cli: 10 passdb: 10 sam: 10 auth: 10 winbind: 10 vfs: 10 idmap: 10 quota: 10 acls: 10 locking: 10 msdfs: 10 dmapi: 10 registry: 10 scavenger: 10 dns: 10 ldb: 10 tevent: 10 Processing section "[global]" doing parameter workgroup = RAMBOLL doing parameter passdb backend = tdbsam doing parameter printing = cups doing parameter printcap name = cups doing parameter printcap cache time = 750 doing parameter cups options = raw doing parameter map to guest = Bad User doing parameter include = /etc/samba/dhcp.conf Can't find include file /etc/samba/dhcp.conf doing parameter logon path = \\%L\profiles\.msprofile doing parameter logon home = \\%L\%U\.9xprofile doing parameter logon drive = P: doing parameter winbind gid = 10000-20000 doing parameter winbind uid = 10000-20000 doing parameter winbind separator = / doing parameter winbind nested groups = yes doing parameter winbind enum groups = yes doing parameter winbind enum users = yes doing parameter winbind refresh tickets = yes doing parameter realm = ZZZ.RAMBOLL-GROUP.GLOBAL.NETWORK doing parameter security = ADS doing parameter template homedir = /home/%D/%U doing parameter template shell = /bin/bash doing parameter mangled names = no doing parameter usershare max shares = 100 doing parameter usershare allow guests = No doing parameter password server = ramstodcZZ.ramboll.ramboll-group.global.network doing parameter server max protocol = smb3 doing parameter log level = auth:10 doing parameter client use spnego = yes doing parameter client ntlmv2 auth = yes doing parameter encrypt passwords = yes doing parameter winbind use default domain = yes pm_process() returned Yes lp_servicenumber: couldn't find homes added interface docker0 ip=172.17.0.1 bcast=172.17.255.255 netmask=255.255.0.0 added interface enp4s0 ip=10.2.10.40 bcast=10.2.10.255 netmask=255.255.255.0 Netbios name list:- my_netbios_names[0]="STO-OPQ-SRC" Client started (version 4.5.3-0-SUSE-oS13.3-x86_64). Opening cache file at /var/lib/samba/gencache.tdb Opening cache file at /var/lib/samba/lock/gencache_notrans.tdb sitename_fetch: Returning sitename for realm 'ZZZ.RAMBOLL-GROUP.GLOBAL.NETWORK': "se-sto" internal_resolve_name: looking up ZZZ.RAMBOLL-GROUP.GLOBAL.NETWORK#20 (sitename se-sto) Adding cache entry with key=[NBT/ZZZ.RAMBOLL-GROUP.GLOBAL.NETWORK#20] and timeout=[Thu Jan 1 01:00:00 1970 CET] (-1488893169 seconds in the past) no entry for ZZZ.RAMBOLL-GROUP.GLOBAL.NETWORK#20 found. resolve_hosts: Attempting host lookup for name ZZZ.RAMBOLL-GROUP.GLOBAL.NETWORK<0x20> remove_duplicate_addrs2: looking for duplicate address/port pairs namecache_store: storing 25 addresses for ZZZ.RAMBOLL-GROUP.GLOBAL.NETWORK#20: 10.192.0.20,10.15.1.18,10.4.2.73,10.194.2.20,10.16.22.2,10.14.101.7,10.160.24.5,10.9.14.10,10.33.0.0,10.4.2.216,10.4.2.74,10.4.3.106,10.4.174.58,10.128.12.110,10.3.0.3,10.14.32.21,10.2.5.22,10.97.2.5,10.193.0.20,10.4.2.214,10.1.1.53,10.144.8.20,10.4.120.26,10.11.161.63,10.2.5.21 Adding cache entry with key=[NBT/RAMBOLL.RAMBOLL-GROUP.GLOBAL.NETWORK#20] and timeout=[Tue Mar 7 14:37:09 2017 CET] (660 seconds ahead) internal_resolve_name: returning 25 addresses: 10.192.0.20:0 10.15.1.18:0 10.4.2.73:0 10.194.2.20:0 10.16.22.2:0 10.14.101.7:0 10.160.24.5:0 10.9.14.10:0 10.33.0.0:0 10.4.2.216:0 10.4.2.74:0 10.4.3.106:0 10.4.174.58:0 10.128.12.110:0 10.3.0.3:0 10.14.32.21:0 10.2.5.22:0 10.97.2.5:0 10.193.0.20:0 10.4.2.214:0 10.1.1.53:0 10.144.8.20:0 10.4.120.26:0 10.11.161.63:0 10.2.5.21:0 Connecting to 10.192.0.20 at port 445 E2BIG: convert_string(UTF-8,CP850): srclen=37 destlen=16 - 'ZZZ.RAMBOLL-GROUP.GLOBAL.NETWORK' Connecting to 10.192.0.20 at port 139 Connecting to 10.15.1.18 at port 445 Connecting to 10.4.2.73 at port 445 Connecting to 10.194.2.20 at port 445 Connecting to 10.16.22.2 at port 445 Connecting to 10.14.101.7 at port 445 Connecting to 10.160.24.5 at port 445 Connecting to 10.9.14.10 at port 445 Connecting to 10.33.0.0 at port 445 Connecting to 10.4.2.216 at port 445 Connecting to 10.4.2.74 at port 445 Connecting to 10.4.3.106 at port 445 Connecting to 10.4.174.58 at port 445 Connecting to 10.128.12.110 at port 445 Connecting to 10.3.0.3 at port 445 Connecting to 10.14.32.21 at port 445 Connecting to 10.2.5.22 at port 445 Connecting to 10.97.2.5 at port 445 Connecting to 10.193.0.20 at port 445 Connecting to 10.4.2.214 at port 445 Connecting to 10.1.1.53 at port 445 Connecting to 10.144.8.20 at port 445 Connecting to 10.4.120.26 at port 445 Connecting to 10.11.161.63 at port 445 Connecting to 10.2.5.21 at port 445 Socket options: SO_KEEPALIVE = 0 SO_REUSEADDR = 0 SO_BROADCAST = 0 TCP_NODELAY = 1 TCP_KEEPCNT = 9 TCP_KEEPIDLE = 7200 TCP_KEEPINTVL = 75 IPTOS_LOWDELAY = 0 IPTOS_THROUGHPUT = 0 SO_REUSEPORT = 0 SO_SNDBUF = 87040 SO_RCVBUF = 372480 SO_SNDLOWAT = 1 SO_RCVLOWAT = 1 SO_SNDTIMEO = 0 SO_RCVTIMEO = 0 TCP_QUICKACK = 1 TCP_DEFER_ACCEPT = 0 session request ok Doing spnego session setup (blob length=120) got OID=1.3.6.1.4.1.311.2.2.30 got OID=1.2.840.48018.1.2.2 got OID=1.2.840.113554.1.2.2 got OID=1.2.840.113554.1.2.2.3 got OID=1.3.6.1.4.1.311.2.2.10 got principal=not_defined_in_RFC4178@please_ignore cli_session_setup_spnego: using target hostname not SPNEGO principal kerberos_get_principal_from_service_hostname: cannot get realm from, desthost ZZZ.RAMBOLL-GROUP.GLOBAL.NETWORK or default ccache. Using default smb.conf realm ZZZ.RAMBOLL-GROUP.GLOBAL.NETWORK cli_session_setup_spnego: guessed server principal=cifs/ZZZ.RAMBOLL-GROUP.GLOBAL.NETWORK@ZZZ.RAMBOLL-GROUP.GLOBAL.NETWORK GENSEC backend 'gssapi_spnego' registered GENSEC backend 'gssapi_krb5' registered GENSEC backend 'gssapi_krb5_sasl' registered GENSEC backend 'spnego' registered GENSEC backend 'schannel' registered GENSEC backend 'naclrpc_as_system' registered GENSEC backend 'sasl-EXTERNAL' registered GENSEC backend 'ntlmssp' registered GENSEC backend 'ntlmssp_resume_ccache' registered GENSEC backend 'http_basic' registered GENSEC backend 'http_ntlm' registered Starting GENSEC mechanism spnego Starting GENSEC submechanism gse_krb5 kerberos_get_principal_from_service_hostname: cannot get realm from, desthost ZZZ.RAMBOLL-GROUP.GLOBAL.NETWORK or default ccache. Using default smb.conf realm ZZZ.RAMBOLL-GROUP.GLOBAL.NETWORK gss_init_sec_context failed with [Unspecified GSS failure. Minor code may provide more information: Server not found in Kerberos database] SPNEGO(gse_krb5) creating NEG_TOKEN_INIT failed: NT_STATUS_INTERNAL_ERROR Failed to setup SPNEGO negTokenInit request: NT_STATUS_INTERNAL_ERROR SPNEGO login failed: An internal error occurred. session setup failed: NT_STATUS_INTERNAL_ERROR I would have thought the following would be the same as the command above (using the workgroup instead of the realm): % smbclient -k -d 10 //RAMBOLL/roropq Netbios name list:- my_netbios_names[0]="STO-OPQ-SRC" Client started (version 4.5.3-0-SUSE-oS13.3-x86_64). Opening cache file at /var/lib/samba/gencache.tdb Opening cache file at /var/lib/samba/lock/gencache_notrans.tdb sitename_fetch: Returning sitename for realm 'RAMBOLL.RAMBOLL-GROUP.GLOBAL.NETWORK': "se-sto" internal_resolve_name: looking up RAMBOLL#20 (sitename se-sto) Adding cache entry with key=[NBT/RAMBOLL#20] and timeout=[Thu Jan 1 01:00:00 1970 CET] (-1488893852 seconds in the past) Could not get allrecord lock on gencache_notrans.tdb: Locking error no entry for RAMBOLL#20 found. resolve_lmhosts: Attempting lmhosts lookup for name RAMBOLL<0x20> getlmhostsent: lmhost entry: 127.0.0.1 localhost getlmhostsent: lmhost entry: 10.160.24.5 RAMBOLL RAMBOLL.RAMBOLL-GROUP.GLOBAL.NETWORK getlmhostsent: group flag in lmhosts ignored (obsolete) resolve_wins: WINS server resolution selected and no WINS servers listed. resolve_hosts: Attempting host lookup for name RAMBOLL<0x20> resolve_hosts: getaddrinfo failed for name RAMBOLL [Name or service not known] name_resolve_bcast: Attempting broadcast lookup for name RAMBOLL<0x20> Connection to RAMBOLL failed (Error NT_STATUS_UNSUCCESSFUL) I cleaned up the Kerberos tickets (kdestroy -A), and got a new one. Just to see that I got a new one. And I did. My current samba config is: [global] workgroup = RAMBOLL passdb backend = tdbsam printing = cups printcap name = cups printcap cache time = 750 cups options = raw map to guest = Bad User include = /etc/samba/dhcp.conf logon path = \\%L\profiles\.msprofile logon home = \\%L\%U\.9xprofile logon drive = P: winbind gid = 10000-20000 winbind uid = 10000-20000 winbind separator = / winbind nested groups = yes winbind enum groups = yes winbind enum users = yes winbind refresh tickets = yes realm = ZZZ.RAMBOLL-GROUP.GLOBAL.NETWORK security = ADS template homedir = /home/%D/%U template shell = /bin/bash mangled names = no usershare max shares = 100 usershare allow guests = No password server = ramstodcZZ.ramboll.ramboll-group.global.network server max protocol = smb3 log level = auth:10 client use spnego = yes client ntlmv2 auth = yes encrypt passwords = yes winbind use default domain = yes An older SAMBA on an older Linux server works in this AD. I don't know how to proceed. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hi Roger,
I'm still fighting with this issue. The Windows server seems not to provide a clue.
LDAP server name: RAMSTODCZZ.ramboll.ramboll-group.global.network Realm: ZZZ.RAMBOLL-GROUP.GLOBAL.NETWORK Bind Path: dc=ZZZ,dc=RAMBOLL-GROUP,dc=GLOBAL,dc=NETWORK
This seems a bit strange. According to ths output: Your DC's fqdn is RAMSTODCZZ.ramboll.ramboll-group.global.network? But your domain is ZZZ.RAMBOLL-GROUP.GLOBAL.NETWORK? So your DC is not part of the domain? Do you have more than one domain in your forest and ZZZ is the root domain? If so, you should bind to the same domain your DC is part of. But if I remember correctly, your krb5.conf did contain the correct server and domain names. Besides that, you seem to have two different problems:
gss_init_sec_context failed with [Unspecified GSS failure. Minor code may provide more information: Server not found in Kerberos database] SPNEGO(gse_krb5) creating NEG_TOKEN_INIT failed: NT_STATUS_INTERNAL_ERROR
Ask your favorite search engine for "Server not found in Kerberos database". You will find a lot of hits - perhaps one of them can lead you to a solution. And
resolve_wins: WINS server resolution selected and no WINS servers listed. resolve_hosts: Attempting host lookup for name RAMBOLL<0x20> resolve_hosts: getaddrinfo failed for name RAMBOLL [Name or service not known] name_resolve_bcast: Attempting broadcast lookup for name RAMBOLL<0x20> Connection to RAMBOLL failed (Error NT_STATUS_UNSUCCESSFUL)
There seems to be a problem with WINS not working as expected. Do you have a "wins server =" entry in your smb.conf? And if so, is the entry correct. [...]
I don't know how to proceed.
If nothing from the things written above will lead you in the right direction I'm really running out of clue.
-- Roger Oberholtzer
Bye. Michael. -- Michael Hirmke -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, Mar 7, 2017 at 8:54 PM, Michael Hirmke <mh@mike.franken.de> wrote:
Hi Roger,
I'm still fighting with this issue. The Windows server seems not to provide a clue.
LDAP server name: RAMSTODCZZ.ramboll.ramboll-group.global.network Realm: ZZZ.RAMBOLL-GROUP.GLOBAL.NETWORK Bind Path: dc=ZZZ,dc=RAMBOLL-GROUP,dc=GLOBAL,dc=NETWORK
This seems a bit strange. According to ths output: Your DC's fqdn is RAMSTODCZZ.ramboll.ramboll-group.global.network? But your domain is ZZZ.RAMBOLL-GROUP.GLOBAL.NETWORK? So your DC is not part of the domain? Do you have more than one domain in your forest and ZZZ is the root domain? If so, you should bind to the same domain your DC is part of.
Sorry about that. In a futile attempt not to provide system names, I changed some of the values. All The ZZZ are really something else. RAMSTODCZZ.ramboll.ramboll-group.global.network should have been RAMSTODCZZ.ZZZ.ramboll-group.global.network
But if I remember correctly, your krb5.conf did contain the correct server and domain names.
Besides that, you seem to have two different problems:
gss_init_sec_context failed with [Unspecified GSS failure. Minor code may provide more information: Server not found in Kerberos database] SPNEGO(gse_krb5) creating NEG_TOKEN_INIT failed: NT_STATUS_INTERNAL_ERROR
Ask your favorite search engine for "Server not found in Kerberos database". You will find a lot of hits - perhaps one of them can lead you to a solution.
I did search for that. I was none the wiser, as they were trying to fix Kerberos. But as kinit and all seem to be working, it does not look like my Kerberos setup is the issue. Maybe kinit is not a complete enough test? The question is: which thing can't it find tin this context that it can fine with kinit? And if something is not known to Kerberos, why is kinit working?
And
resolve_wins: WINS server resolution selected and no WINS servers listed. resolve_hosts: Attempting host lookup for name RAMBOLL<0x20> resolve_hosts: getaddrinfo failed for name RAMBOLL [Name or service not known] name_resolve_bcast: Attempting broadcast lookup for name RAMBOLL<0x20> Connection to RAMBOLL failed (Error NT_STATUS_UNSUCCESSFUL)
There seems to be a problem with WINS not working as expected. Do you have a "wins server =" entry in your smb.conf? And if so, is the entry correct.
I do not have this in my smb.conf. On Windows PCs in the network, DNS is defined. But no WINS servers are listed. I tried setting the server to the DNS servers (maybe the DNS server also provides WINS). No difference. I also do not have the wins server defined on the SAMBA machine (samba-3.6.12) that works. Sigh. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (3)
-
John Andersen -
mh＠mike.franken.de -
Roger Oberholtzer