fs-cifs connect problem

I’ll be the first to confess I don’t understand th Windows side of this.
I am trying to mount two Windows servers from my 6.2.1B box. The first
works and the second one does not. I have:
fs-cifs &
mount -t cifs -obill,xxx //FIRST_SERVER:192.168.1.23:/ /fs/first_server
mount -t cifs -obill,xxx //SECOND_SERVER:192.168.1.25:/ /fs/second_server
(The names have been changed to protect the innocent!)
The first mount works, the second mount does not.

I was told by one of our MIS guys that the difference is that FIRST_SERVER
is also out domain server adn to connect to the SECOND_SERVER the mount
must know to authenticate the login with FIRST_SERVER. He gave me a SAMBA
config file that looks like this:
security=domain
password server=FIRST_SERVER
damain=Our_Company

How do I apply this to the Neutrino version of fs-cifs?

Bill Caroselli wrote:

I’ll be the first to confess I don’t understand th Windows side of this.
I am trying to mount two Windows servers from my 6.2.1B box. The first
works and the second one does not. I have:
fs-cifs &
mount -t cifs -obill,xxx //FIRST_SERVER:192.168.1.23:/ /fs/first_server
mount -t cifs -obill,xxx //SECOND_SERVER:192.168.1.25:/ /fs/second_server
(The names have been changed to protect the innocent!)
The first mount works, the second mount does not.

I was told by one of our MIS guys that the difference is that FIRST_SERVER
is also out domain server adn to connect to the SECOND_SERVER the mount
must know to authenticate the login with FIRST_SERVER. He gave me a SAMBA
config file that looks like this:
security=domain
password server=FIRST_SERVER
damain=Our_Company

I’m no Windows guru either but AFAIK the responsibility for authentication
rests with the server (not the client - who simply must supply credentials).
Think about it - if the SECOND_SERVER simply “believed” fs-cifs, who
“promised” that he did discuss his credentials with FIRST_SERVER, and
FIRST_SERVER said he is allowed to connect to SECOND_SERVER - then
SECOND_SERVER would be rather naive and ripe for exploitation.

Rennie

Rennie Allen wrote:

Think about it - if SECOND_SERVER simply “believed” fs-cifs, who
“promised” that he did discuss his credentials with FIRST_SERVER, and
FIRST_SERVER said he is allowed to connect to SECOND_SERVER - then
SECOND_SERVER would be rather naive and ripe for exploitation.

Actually, I just realized I get duped like this all the time.

Replace SECOND_SERVER with “I” FIRST_SERVER with “mommy”, fs-cifs
with “my six year old son” credentials with “request to ride bike
to the playground” and “connect to SECOND_SERVER” with “ride bike
to playground” and you’ll have an account of how :wink:

I was told by one of our MIS guys that the difference is that FIRST_SERVER
is also out domain server adn to connect to the SECOND_SERVER the mount
must know to authenticate the login with FIRST_SERVER. He gave me a SAMBA
config file that looks like this:
security=domain
password server=FIRST_SERVER
damain=Our_Company

I believe you can add these to the [global] section of your
/etc/samba/smb.conf file. I was able to find the following on the samba
website which may be helpful:

http://us1.samba.org/samba/docs/man/smb.conf.5.html#SECURITY


Cheers,
-Barry

bbeldam <bbeldam@qnx.com> wrote:

I was told by one of our MIS guys that the difference is that FIRST_SERVER
is also out domain server adn to connect to the SECOND_SERVER the mount
must know to authenticate the login with FIRST_SERVER. He gave me a SAMBA
config file that looks like this:
security=domain
password server=FIRST_SERVER
damain=Our_Company

b > I believe you can add these to the [global] section of your
b > /etc/samba/smb.conf file. I was able to find the following on the samba
b > website which may be helpful:

b > http://us1.samba.org/samba/docs/man/smb.conf.5.html#SECURITY


Back to the original question. Does this mean that the “fix” has to
happen on the Windows system?

Remember, I’m trying to access a Windows filesystem from QNX.

Bill Caroselli wrote:

Back to the original question. Does this mean that the “fix” has to
happen on the Windows system?

AFAICT yes. Your problem definately has nothing to do with Samba, since
(according to your description) it is not involved at all.

bbeldam <bbeldam@qnx.com> wrote:
b > Rennie Allen wrote:

Bill Caroselli wrote:

Back to the original question. Does this mean that the “fix” has to
happen on the Windows system?


AFAICT yes. Your problem definately has nothing to do with Samba, since
(according to your description) it is not involved at all.

b > The windows network will have to be configured to use first_server as
b > the domain authenticator, but if his IS people gave him the config
b > information he posted then I’m assuming it’s already set up to work that
b > way, and he just has to have his client authenticate to first_server,
b > rather than to second_server as it normally would.

b > It’s possible I’m just confused, of course. :slight_smile:


Yes. Again, my MIS folks are saying that that is the way it is
configured. Also, I have a Windows-XP box that DOES connect to both
servers correctly.

So, the question remains, Is there something that I can do on my QNX
system to connect to this other server just as my Windows-XP system
can?

b > I believe you can add these to the [global] section of your
b > /etc/samba/smb.conf file. I was able to find the following on the samba
b > website which may be helpful:

b > > http://us1.samba.org/samba/docs/man/smb.conf.5.html#SECURITY


Back to the original question. Does this mean that the “fix” has to
happen on the Windows system?

No, you should just have to modify the configuration on your QNX client.
The windows network should presumably already be configured to use
first_server as a domain authenticator; you just need to let your QNX
client know who to present its credentials to.

Remember, I’m trying to access a Windows filesystem from QNX.

You wrote:

I was told by one of our MIS guys that the difference is that
FIRST_SERVER
is also out domain server adn to connect to the SECOND_SERVER the mount
must know to authenticate the login with FIRST_SERVER.

Assuming your IS contact is correct, then your windows network is
configured to use first_server for authentication. In this case, anyone
(windows or otherwise) trying to mount shared resources will have to
present their credentials to first_server. The config file you were
provided will instruct your QNX client to authenticate itself to
first_server.

Our client will trust that second_server will know about this and that
there will be a mechanism in place for second_server to query
first_server as to our credentials.

Assuming that the windows network is set up the way that your IS people
suggest it is, then adding the lines you were provided to the smb.conf
file on your QNX client should allow you to connect.

Note that you’ll also have to turn on encrypted passwords in your
smb.conf file, and ensure that the username and password you supply
matches the username and password of a user on first_server who has
access to the resources on second_server.


Cheers,
-Barry

Rennie Allen wrote:

Bill Caroselli wrote:

Back to the original question. Does this mean that the “fix” has to
happen on the Windows system?


AFAICT yes. Your problem definately has nothing to do with Samba, since
(according to your description) it is not involved at all.

The windows network will have to be configured to use first_server as
the domain authenticator, but if his IS people gave him the config
information he posted then I’m assuming it’s already set up to work that
way, and he just has to have his client authenticate to first_server,
rather than to second_server as it normally would.

It’s possible I’m just confused, of course. :slight_smile:


Cheers,
-Barry

bbeldam <bbeldam@qnx.com> wrote:


b > Assuming your IS contact is correct, then your windows network is
b > configured to use first_server for authentication. In this case, anyone
b > (windows or otherwise) trying to mount shared resources will have to
b > present their credentials to first_server. The config file you were
b > provided will instruct your QNX client to authenticate itself to
b > first_server.

b > Our client will trust that second_server will know about this and that
b > there will be a mechanism in place for second_server to query
b > first_server as to our credentials.

b > Assuming that the windows network is set up the way that your IS people
b > suggest it is, then adding the lines you were provided to the smb.conf
b > file on your QNX client should allow you to connect.

b > Note that you’ll also have to turn on encrypted passwords in your
b > smb.conf file, and ensure that the username and password you supply
b > matches the username and password of a user on first_server who has
b > access to the resources on second_server.

OK. Now we’re getting somewhere (I hope!)

I don’t have a smb.conf file (at least not in /etc). Where should it
be and what needs to be in it?

Also, I don’t find this file documented. Is it?

I also did not find any:
strings /usr/sbin/fs-cifs | grep smb.conf

Bill,

I’ve done some more digging and talked to our resident SMB expert and it
appears that my understanding of your situation is correct but I’ve
become confused about how to fix it :slight_smile:

The options you were provided by your IS contact are (or appear to be)
smb.conf options, but I had a mental disconnect as to the fact that
you’re connecting with fs-cifs (which doesn’t use smb.conf) so we’ll
have to try to do what he was suggesting in a different way. I
apologize for the confusion.

Unfortunately, the 6.2.1 version of fs-cifs doesn’t have the ability to
use a domain authenticator in the manner required by your windows
network. This leaves us with the following options, in rough order of
desirability:

  1. On second_server, create a local user and password which matches the
    username and password with which you are attempting to connect. On some
    windows versions, the machine will attempt to locally authenticate
    before it falls back on its domain authentication policy, so if the user
    information you’re providing matches a local user, you might be able to
    avoid the domain authenticator entirely.

  2. Try to have the authentication policy of your network changed to
    allow second_server to do its own authentication.

  3. Wait for 6.3.0. The upcoming version of fs-cifs will be able to
    specify a domain authenticator to handle this kind of situation.


    Again, I apologize for the confusion.


    Cheers,
    -Barry

bbeldam wrote:

  1. On second_server, create a local user and password which matches the
    username and password with which you are attempting to connect. On some
    windows versions, the machine will attempt to locally authenticate
    before it falls back on its domain authentication policy, so if the user
    information you’re providing matches a local user, you might be able to
    avoid the domain authenticator entirely.

  2. Try to have the authentication policy of your network changed to
    allow second_server to do its own authentication.

  3. Wait for 6.3.0. The upcoming version of fs-cifs will be able to
    specify a domain authenticator to handle this kind of situation.

Interesting. We use domain authentication here, and it works fine with
the current fs-cifs, I can connect to any number of our Windows servers
with fs-cifs while we have only 1 domain controller. If the network
admin changes my password on the domain controller, then I have to
change the password I provide to fs-cifs. If I type in an incorrect
password while trying to mount a share on any of our Windows servers
it will fail (just to show that authentication is actually occuring).
None of our Windows servers (with the exception of the PDC) has any
user accounts (other than the default Administrator etc.).

I know that we use centralized authentication because I also have a
Samba server running, and I had to configure it to do authentication
with the PDC (which supports my contention that authentication is the
responsibility of the server not the client - this should be obvious,
even if it is M$ we’re talking about). I also had to register the Samba
server as a server within the domain before the PDC would authenticate
requests on its behalf.

Until I configured the Samba server to authenticate with the PDC nobody
(including fs-cifs) could connect to it, since there are, in fact, no
Windows accounts on the Samba server (it has “security=domain” set in
smb.conf), and it defers all authentication requests to the PDC.