domain based access

[beks6]

Is it possible to access a SMB Share over VPN? My current approach looks like this

session = TOSMBSession(hostName: "hostName", ipAddress: "192.168.0.10")
session.setLoginCredentialsWithUserName("username", password: "password")
var files: [Any]? = try! self.session.requestContentsOfDirectory(atFilePath: "/")

This is the error message I get

fatal error: 'try!' expression unexpectedly raised an error: Error Domain=TOSMBClient Code=1003 "Login authentication failed." UserInfo={NSLocalizedDescription=Login authentication failed.}: file /Library/Caches/com.apple.xbs/Sources/swiftlang/swiftlang-802.0.53/src/swift/stdlib/public/core/ErrorType.swift, line 182

The same way works for a NAS (buffalo) which is physically in the same room.

Is it possible it fails because the SMB I try to access is on a Windows Server?

Hardware / Software

TOSMBClient v1.0.7 over cocoapods Testing on iOS Simulator 10.0 I'm using this library with Swift 3

Goals

Connect to SMB share which is reachable over VPN

[TimOliver]

That's a very good question! I've always used this library on my home network, so I've never tried it on a VPN myself.

My NAS is a Linux powered Synology, but I'm pretty sure I tested it against one of my Windows PCs running Windows 10 without issue as well.

That error is triggered here when a call to smb_session_login() from libdsm fails.

You can inspect the code in that repo if you want and see if you notice anything. It's all low-level TCP interactions, and I'm not sure if enabling a VPN on an iOS device will automatically handle that on the system level or if the code here needs to do something as well.

[beks6]

OK, I think I found something

You are setting here the hostName as Domain, this could be the reason for my problem :). But in this case it shouldn't be a VPN problem

I'll check it tomorrow

[beks6]

I hardcoded the domain name for testing purpose and got immediatly the number of folders on root.

Maybe you could add another method which accepts domains if it's provided/needed?

Another approach could be to parse the domain out of the hostName

f.e.: TOSMBSession(hostName: "hostName.domain.com", ipAddress: "192.168.0.10") in this case the session should create two variables hostName = hostName and domain = domain.com this could lead to something like

if domain.isEmpty {
    domain = hostName
} else {
    domain = (subString of hostName)
}

[TimOliver]

Oh wow! Nicely done!

Hmm, okay. I wonder what the best way of supporting this would be then. What's stopping you from simply doing TOSMBSession(hostName: "domain.com", ipAddress: "192.168.0.10") at the moment?

I wonder if just renaming public references of hostName to domain would be more concise.

[beks6]

OK, it surprises me that it works with this approach, because normally the full name is "servername.domain.com"

In this case we are not really providing the servername and I'm not sure how stable this is.

PS: I changed the title of the issue

[TimOliver]

Hmm, looking at the libdsm headers again, and in there, both domain and hostname are used for connecting and then setting the credentials.

I think your suggestion might have been right the first time. It might be worth making domain a completely separate externally accessible property, and if it isn't set by the host app, then hostName is used in its place.

[beks6]

Yes, thanks to their good naming of variables the bug was easy to find, when I investigated your first answer. There are several other SMB libraries on github who use libdsm and have the same bug.

Yes, I think this would be a more secure/stable approach to establish the connection. Or consider maybe adding another initializer which expects a domain value.

[tnavadiya]

Is your latest example code works with domain/username method?

[beks6]

hello @tnavadiya, I solved this issue for my purpose by providing the domain name as hostName because otherwise you have to change the TOSMBSession method

In fact by doing this, you are then just accessing the Server over the IP Address