Windows computers can not access smb-shares in Lion

Interesting. Mine is (was) a lion server with od accounts and I wanted to connect to the server shared folders authenticating with these and not local accounts (as there are none and I refuse to create 2 accounts per user......) Anyway, will give it a try on another day, when I am willing to resurrect the frightful Lion Server once again.

🙂

Connecting Windows 7 computers to a standalone Lion Server running as Open Directory master:

You can lower the required security settings for Windows 7 via secpol.msc (Win 7 Pro) or editing the registry as some how-to's will suggest - this has been a suggestion made for resolving problems authenticating from Vista to earlier verions of Mac OS X Server. See mambro's post above, or

http://www.macwindows.com/OSXServer.html#050310c

In this day and age of increasing (and valid) concerns over security, many may prefer to not *decrease* the security for network authentication on their Windows workstations.

Bear in mind that the following tip is for Lion Server that is not part of an Active Directory Domain!

If that is the case with your server, stop here and do not proceed. Instead, seek out and work with your network administrar(s) and Active Directory admin(s). Your server should already have been bound to your AD domain - for example in what's known as a "Golden Triangle" setup - and you should resolve authentication issues with your admins, as your client machines should be authenticating against AD.
With a standalone setup of Lion Server (you have setup Lion server on a single Mac) promoted to an Open Directory Master, your 10.7 Server can provide Kerberos authentication for your Windows client machines. The problem is that your Win machines don't know anything about your Lion server and won't trust it as a KDC.

There is a helpful document from ncsa.illinois.edu,

https://wiki.ncsa.illinois.edu/display/ITS/Windows+7+Kerberos+Login+using+Extern al+Kerberos+KDC

which summarizes the steps you can take, of course adjusting accordingly for your own server & FQDN,

please do not use any hostnames in that article !!!

Please ensure that you have verified the Kerberos realm for your Lion server. Unless you have specified otherwise (for good reason), then it will match the FQDN (dns name) for your server, but should be written in all-caps (see http://www.afp548.com/article.php?story=20060709175021180

to learn more about Kerberos)

The key steps being (on your Win 7 workstation):

Ksetup /setdomain SERVER.YOURNAMEHERE.COM

Ksetup /addkdc SERVER.YOURNAMEHERE.COM server.yournamehere.com

After taking the steps above, and rebooting the Windows client machine,

I added one additional step from Microsoft, (please do see)

http://technet.microsoft.com/en-us/library/cc757218(WS.10).aspx

/AddKpasswd RealmName KpasswdName

thus:

Ksetup /AddKpasswd SERVER.YOURNAMEHERE.COM server.yournamehere.com

You can then connect to your Lion server via (an Explorer window) (editing accordingly for the shortname

of your server:

\\Server\Sharepointname

at which point you'll be asked to authenticate and should be able to do so successfully and connect to the sharepoint in question, as long as the user in question (that you have authenticated as), has indeed already been assigned appropriate access permissions on your server.

Other sharepoints that the same user has authorization to access on your Lion Serve, s/he should also now be able to access. Keep in mind that the default setting in Server.app (where you setup your sharepoints in Lion server) sets Read Access for "Everyone Else" - you might wish or need to change Read-Access to No Access to prevent users from seeing the sharepoint altogether.

-- David Haines (ACTC, ACSA)

Wow. I am impressed and thankful. Assuming this will also work on earlier windows versions.

Have a great weekend. Grateful for this discussion forum.

Kim (ACTC, ACSP)

This article from Microsoft refers to Win XP Pro,

http://technet.microsoft.com/en-us/library/cc736890(WS.10).aspx

But I haven't tested the procedure (as outlined by me above) with Windows XP (nor with Vista) & Lion Server, only Windows 7.

Update for XP client. Not able to login.

Tried ksetup configuration on an XP Pro machine. Installed the XP Support Tools to get ksetup.exe. Ran the commands as outlined in post. No errors running ksetup. Restart.

But still can't authenticate to Lion Server OD account.

Tomorrow I'll try from a Windows 7 machine.

(Looks like I'll be downgrading to SL server. What a pain.)

Yes it is a pain especially when one has no choice but to purchase a lion server when as is our case, our server dies... Cannot even buy a refurbished macmini running SL from apple.... already looked. The Lion server macmini is shelved for now.

FWIW...

After upgrading my production OD master server from 10.6.8 to 10.7.1 last night, I can confirm that the need to use the 10.7.1 netbios name as part of the "User Name" when logging in from Windows 7 -- is now needed.

So, what was "maser" is now "LIONSERVERNETBIOSNAME\maser".

It was not an expected change, but once I flipped through all the logs (and the debug logs for smbd pointed me in the right direction), it was telling me this if I tried to authenticate without the netbios name:

gss_parse_external_name [gssapi.cpp:118] mapped GSS name SPY\maser to SPY\maser

initialize [darwin_token.cpp:297] failed to turn exported name into uuid: No such file or directory

Where "SPY" is the Windows 7 Computer name (which shows as the "Domain" name in the Windows Security "Enter Network Password" dialog box)

If I changed the login User Name in the Network connection box to "SERVER\maser" -- which just the act of typing "SERVER\" updates the "Domain:" in that box -- then the connection works as expected.

It *is* a Kerberos-related issue, clearly. The krb5kdc logs show things like:

2011-08-25T13:40:38 digest-request: user=SPY\\maser

2011-08-25T13:40:38 digest-request: kdc failed with 36150275 proto=unknown

2011-08-25T13:40:38 digest-request: guest failed with 22 proto=ntlmv2

But what's still not clear to me is if there's something that can be changed on either end to make things work like they did with 10.6.8 server (kerberos change? Something in com.apple.smb.server.plist? Something on the Windows side (which, for all points before this, has never required me to configure Kerberos on it for any reason...)

I'd like to know if this is a "bug" or by design now...

I think you've narrowed it down, Steve, but a related issues is trying to connect multifunction printers with scan settings that are supposed to be able to scan documents, and write their output to an SMB share. I have several clients who did this just fine under Snow Leopard, entering username / password for the SMB user and share in the SnoLo server. Now, under Lion, those connections don't work. After adding the NetBIOS name, LIONSERVERNETBIOSNAME\username, it STILL doesn't work. I confirmed that others have found this to be an issue when I was poking around the documentation for Xerox's Lion support PDF...

While digging around for a printer recommendation for a client, I was looking at Xerox's PDF on Lion compatibility <http://download.support.xerox.com/pub/drivers/Compatibility_Matrix/other/macosx/ en/MacOSX10-7_Matrix.pdf>, which is very good. However, on page 10 they state...

"Scan Driver Compatibility with Mac OS X 10.7

"Some scan functionality is diminished in Mac OS X 10.7. In particular, scanning via the SMB protocol is no longer supported due to architectural changes in Mac OS X 10.7. Please continue to visit Xerox.com/drivers periodically for updates regarding enhancements to scan drivers that address this change."

So, it's nice to know I'm not crazy, and Apple's switch from using Samba to their own SMB flavor has broken something, and big guns like Xerox have an issue too.

Thank you David for getting me on the right path! OMG!!! The only change I would make is that I thought I performed the steps as you layed them out and it changed the client's workgroup to: server.yournamehere.com. (yes I replaced that with the name of my Kerberos server) I changed the workgroup back to the correct workgroup name... rebooted the PC client... input the IP address of the share in Windows Explore and voila!!

Why the **** didn't Apple let us know about this!!

BTW, What would someone do if they didn't have an XP disc lying around with the Ksetup tool to be installed? I couldn't find the same tool on my Win7 disc. Hmmmmmm...

oops! Ignore that last remark. It only worked because I used an account that was also a local account on the server. Network accounts still not working. 😟

I'll have to revisit the steps when I can, but it was a fairly striking A/B result (not working, then working after the steps I outlined), and with network accounts being the only kind I was testing with.

Make sure your client machine is pointed to your server for DNS, or that you have working DNS lookups including the necessary service records, and said (DNS) servers are what are being provided (via DHCP) to your client machines.

hacking the registry fixed this for me Well done that man !

I've been beating my head against the wall for hours and I finally came up with a solution that doesn't involve Kerberos.

First, I had to make sure my WINS name matched my DNS name. My machine's DNS is "office" but I had titled it "mini-server", so when I was on the Windows 7 machine I saw "mini-server" but when I tried to click on it I was told that it didn't really exist (or something — I think it said "check the spelling").

Second was a combination of two tips from earlier in the thread: I had to change my username from "ctj" to "OFFICE\ctj". The prefix is important, and the capitals are important.

This is an Open Directory account, and when I logged on that way all the files came up exactly like one would expect. If you have a user with a local account who needs to log in, you can just use their username without the prefix.

Hope this helps someone!

Also, this might be important also: In Server Admin, I changed the SMB setting from allowing only some users & groups to allowing all users & groups. Not at all straight-forward, but this setup works!

Not sure what's happening for you - is DNS all set ?

Adding the workgroup to my login was not necessary. After taking the steps I outlined originally,

I was able to connect as the username only, not WORKGROUP\username

and connected fine with an OD account.