smbclient problem

Y

YuryG

Well, installed samba, I still can't get access to Windows share, easily accessible on near Windows computers.
It says "invalid parameter", but I can't figure out what's wrong. Configuration files are empty.
Code: 
$ smbclient -d4 -I 172.x.x.x -U WORKGROUP/u --password p \\\\172.x.x.x\\m
lp_load_ex: refreshing parameters
Initialising global parameters
Processing section "[global]"
pm_process() returned Yes
added interface age0 ip=172.x.y.y bcast=172.x.y.255 netmask=255.255.255.0
added interface wlan0 ip=192.168.0.1 bcast=192.168.0.255 netmask=255.255.255.0
Client started (version 4.19.7).
Connecting to 172.x.x.x at port 445
 session request ok
 negotiated dialect[SMB2_10] against server[172.x.x.x]
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 'ncalrpc_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
GENSEC backend 'http_negotiate' registered
GENSEC backend 'krb5' registered
GENSEC backend 'fake_gssapi_krb5' registered
Cannot do GSE to an IP address
Failed to start GENSEC client mech gse_krb5: NT_STATUS_INVALID_PARAMETER
Got challenge flags:
Got NTLMSSP neg_flags=0x628a8215
  NTLMSSP_NEGOTIATE_UNICODE
  NTLMSSP_REQUEST_TARGET
  NTLMSSP_NEGOTIATE_SIGN
  NTLMSSP_NEGOTIATE_NTLM
  NTLMSSP_NEGOTIATE_ALWAYS_SIGN
  NTLMSSP_TARGET_TYPE_SERVER
  NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY
  NTLMSSP_NEGOTIATE_TARGET_INFO
  NTLMSSP_NEGOTIATE_VERSION
  NTLMSSP_NEGOTIATE_128
  NTLMSSP_NEGOTIATE_KEY_EXCH
gensec_spnego_client_negTokenTarg_step: SPNEGO(ntlmssp) login failed: NT_STATUS_INVALID_PARAMETER
SPNEGO login failed: An invalid parameter was passed to a service or function.
session setup failed: NT_STATUS_INVALID_PARAMETER
May be someone could help, it shouldn't be that cumbersome task to access SMB, should it?
 
Code: 
Cannot do GSE to an IP address
Failed to start GENSEC client mech gse_krb5: NT_STATUS_INVALID_PARAMETER

What happens if you use the hostname, i.e. //hostname/share, instead of the IP address?
 
SirDice said:
Code: 
Cannot do GSE to an IP address
Failed to start GENSEC client mech gse_krb5: NT_STATUS_INVALID_PARAMETER

What happens if you use the hostname, i.e. //hostname/share, instead of the IP address?
Click to expand...
I do not have a hostname, it's only an IP in the local network.
 
YuryG said:
It's a corporate local network
Click to expand...
IP addresses don't matter, the question was if the Windows host was AD joined or not. If it's AD joined then -U DOMAIN\\username should be used if username is an AD account. Or you can use the username@DOMAIN.REALM notation. If it's a local account it should be -U hostname\\username. If it's AD joined it will probably also have NTLM authentication turned off.
 
SirDice said:
IP addresses don't matter, the question was if the Windows host was AD joined or not. If it's AD joined then -U DOMAIN\\username should be used if username is an AD account. Or you can use the username@DOMAIN.REALM notation. If it's a local account it should be -U hostname\\username. If it's AD joined it will probably also have NTLM authentication turned off.
Click to expand...
I am not sure what do you mean, this NAS has its own IP, and there are different shares on it. I have been given its IP, username, password and share name from an administrator (which is sufficient to access it from Windows computer). (172.x.x.x, u, p and m in my example respectively). Our computers have addresses from the same group (172.x.y.y).
 
YuryG said:
(which is sufficient to access it from Windows computer)
Click to expand...
Active Directory (ADS) uses Kerberos for authentication. That Windows computer probably has a kerberos host principle (joining a domain creates it) that allows it to talk to AD. Your FreeBSD machine doesn't have a host principle and can therefor not authenticate with active directory.

IP addresses are all irrelevant, I'm sure the admins have set up their network correctly, so routing or connectivity itself is not the issue here.
 
SirDice said:
Active Directory (ADS) uses Kerberos for authentication. That Windows computer probably has a kerberos host principle (joining a domain creates it) that allows it to talk to AD. Your FreeBSD machine doesn't have a host principle and can therefor not authenticate with active directory.

IP addresses are all irrelevant, I'm sure the admins have set up their network correctly, so routing or connectivity itself is not the issue here.
Click to expand...
I'm not sure this is the case. How can I check it? Or how to "join a domain" if it is the case?
I can access web-interface of this NAS from FreeBSD (or Windows computer), so IP is definitely accessible. (Although dhclient gives "Bogus domain search list" warnings regularly on the console and DHCP gives empty "new hostname".)
 
YuryG said:
I can access web-interface of this NAS from FreeBSD
Click to expand...
Web interface probably authenticates underwater with AD directly, or maybe the LDAP interface of AD, and simply presents you with a login page.

YuryG said:
How can I check it?
Click to expand...
Just ask your admins.

YuryG said:
Or how to "join a domain" if it is the case?
Click to expand...
You would need to have an AD account that has the "Create Computer Objects" permission. Or ask an admin to create the computer account for you and give you the generated host principle.
 
SirDice said:
Web interface probably authenticates underwater with AD directly, or maybe the LDAP interface of AD, and simply presents you with a login page.


Just ask your admins.


You would need to have an AD account that has the "Create Computer Objects" permission. Or ask an admin to create the computer account for you and give you the generated host principle.
Click to expand...
Well, it finally worked when I changed my hostname to be of form of near computers ("labXX-Y")!
Suppose, the problem was the empty hostname (which is recommended since it should be filled by DHCP server, but it's not my case).
 
You must log in or register to reply here.
Back
Top