Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

SMB still broken in 10.5.8, broken kerberos seems to be the issue

When first installed my production Xserve and OS X 10.5.1 provided SMB sharing flawlessly, tat is until a 10.5.4 update after which it was broken. I've waited for new updates to see if it will be fixed but to no avail, so after applying 10.5.8 I decided to do some investigation. Fortunately I have a test server (in which SMB is OK) to compare and test with. These are my findings:-

Attempt to connect to production server with Go command, smb://10.0.0.100, no password dialogue box, Connection Failed box appears, accept, further message "cannot connect to the server because the name or password is not correct"
Attempt to connect to test server with Go command, smb://172.16.0.100, get password dialogue box, enter user name and password and a list of shares appears.

Now do the same with terminal just to see if authentication is the problem
Production server, > smbclient //10.0.0.100/ -U Administrator, message "connection refused"
Test server, > smbclient //172.16.0.100/ -U Administrator, prompt comes back for "password"

So now I take a look at the smb.conf file in /etc
both files are the same

Then I look at the smb.conf in /var/samba/db
A difference.
In the test sever (where smb works), global is defined as
[global]
security = USER
auth methods = guest odsam
netbios name = leopard
workgroup = workgroup
realm = LEOPARD.XXXXXX.XXXX.XXX
dos charset = 437
server string = leopard
ntlm auth = yes
lanman auth = no
max smbd processes = 100
log level = 1
use kerberos keytab = yes
realm = LEOPARD.XXXXXX.XXXX.XXX
map to guest = Bad User
wins server = 172.16.0.190
domain master = yes
preferred master = yes
os level = 65
enable disk services = yes
enable print services = yes
wins support = no

In the production server (where smb is broken), global is defined as:-
[global]
security = USER
auth methods = guest odsam
netbios name = OSX-Server
workgroup = WORKGROUP
dos charset = 437
server string = server
ntlm auth = yes
lanman auth = no
max smbd processes = 0
log level = 2
map to guest = Bad User
domain master = yes
preferred master = yes
os level = 65
enable disk services = yes
enable print services = yes
wins support = no

The differences between the two are in the good test server "realm = LEOPARD.XXXXXX.XXXX.XXX" appears in two places as does "use kerberos keytab = yes" Note XXXX's used to obscure domain

So where do I go from here in my fault diagnosis?
I can provide copies of files, conduct test, just ask.

Xserve,Leopard Server, Mac OS X (10.5.8)

Posted on Aug 16, 2009 8:14 AM

Reply
19 replies

Aug 17, 2009 6:37 AM in response to Dave Hall - MacFusion

It seems from your description and my experience your issue lies deeper then SMB. I would take the OD Master and demote it to standalone. And then repromote it back to Master. Before doing so you will need to take PDC and make it standaone as well. BE cautious as users, passwords in OD will be gone unless you have a complete backup. Also any computer on the domain will need to be re-added. Once you have it back to stand alone, reboot. I would then go ahead and make it the OD master, and as always the only think you should need to type in is the OD master password. Once that is complete reboot. After reboot, take the SMB and make it the PDC. Reboot. Then finally make a test user and try to log in.

You can try this although not sure:
Run this command:
sudo mkpassdb -kerberize
Then take the PDC demote it and then re-promote it.

Let us know.

Aug 17, 2009 12:20 PM in response to Dave Hall - MacFusion

Well your thoughts re OD are in-line with my observations. To try this out I need to prepare an impact statement and your thoughts would be appreciated. My paranoia in the work is losing all the relationships between users, shares, calendars, passwords, etc. To reduce this back up I would archive OD as well as all the other back up options is server admin, plus create back-ups of all users and groups in Workgroup Manager. So with that said your thoughts on potential pitfalls, disaster recovery options, would be most appreciated.

Aug 17, 2009 12:52 PM in response to Dave Hall - MacFusion

Well if the Windows are on the PDC even if you name it the same the work stations would need to be dropped back to Workgroup and then back to domain level. Users and passwords I have had issues with even with a backup, so I normally do a full reset. I would also ensure that a backup was completed by opening it on a test server to make sure all data is complete. I havent seen a groups go bad where the users were not in the right group. Shares same, never had an issue. Calendars I can not speak for. Does this help?

Aug 17, 2009 7:34 PM in response to Dave Hall - MacFusion

Obvious question, did you try stopping the 'smb' service and then adding the lines:

realm = ODSERVER.DOMAIN.TLD
use kerberos keytab = yes
realm = ODSERVER.DOMAIN.TLD

to the appropriate places in the /var/db/smb.conf file on your production server and then restart the 'smb' service?

Also, change the line ' log level = 2' to ' log level = 9', then take a look at /var/log/samba/log.smbd after you try to login. There should be significantly more information there than the default setting of '2' provides.

Aug 18, 2009 12:43 AM in response to Dave Hall - MacFusion

I did edit the file to try and impose this, but if you check out the first few comments of the file it is auto generated by the server, and sure enough the changes did not flow through. I've seen other notes talking about appending the smb.conf in /etc but nothing substantive. It seems that there is a standard smb.conf file which is then "edited" by the server to meet it's needs drawn on all the parameters it can groom from OD, share rights, etc and this is not editable. I think rkovelman is right, the root of the issue is inside OD not communicating it's set-up to the process that generates the final smb.conf file.
I really wish Apple would provide a meaningful tool kit for Leopard server to allow sys admins to fix broken components of the server.

Aug 18, 2009 11:57 AM in response to Dave Hall - MacFusion

rkovelman not yet tried the demotion/promotion of the domain controller. I have to convince the business owner that the risk is minimal or at least can be minimised. Fortunately the Xserve HD is mirrored as is the data drive & Time Capsule back up drive. I need to budget 1 day worst case during a weekend. If anyone has any good ideas on how to minimise the risk I'd like to know. Until I get permission for this grand experiment then this post will go quiet from me until the work is undertaken. Thanks to everyone who has contributed. If there are any other folks with ides please post them so I can add to my knowledge base.

Aug 18, 2009 6:27 PM in response to rkovelman

It is possible to tear down and hand-crank Kerberos, without demoting OD to standalone.

But in my experience there are SO many variables including things that can too easily be overlooked,
for it to be feasible to help someone try to to do so on an informal basis via a forum.

Certainly do have a look at Apple's article,
http://support.apple.com/kb/HT3655

start by making sure your DNS is good - check forward and reverse lookups for your server via
dig <FQDN>
and
dig -x XX.IP.ADDRESS

plus of course
sudo changeip -checkhostname


also check
scutil --get HostName


and
dscl /LDAPv3/127.0.0.1 -read /Config/KerberosKDC > KerberosKDC.out; cat KerberosKDC.out


Also, finally, see Gerrit DeWitt's post here:
http://discussions.apple.com/message.jspa?messageID=5917575

Aug 23, 2009 12:05 PM in response to Dave Hall - MacFusion

Some progress at last, I used Gerrit's hint to attempt to kerberize smb using sso_util. The transcript below is the terminal output and then a comparison or /var/db/smb.conf

------------------------------
Attempt at using sso_util for smb only

server:~ admin$ sudo sso_util configure -r SERVER.JMLECTERNS.CO.UK -a diradmin smb
Password:
Contacting the directory server
/Local/Default
/BSD/local
/LDAPv3/127.0.0.1
Creating the service list
Creating the service principals
WARNING: no policy specified for cifs/server.jmlecterns.co.uk@SERVER.JMLECTERNS.CO.UK; defaulting to no policy
add_principal: Principal or policy already exists while creating "cifs/server.jmlecterns.co.uk@SERVER.JMLECTERNS.CO.UK".
Creating the keytab file
Configuring services
WriteSetupFile: setup file path = /temp.cezX/setup


#
# Configuration options for smbd(8), nmbd(8) and winbindd(8).
#
# This file is automatically generated, DO NOT EDIT!
#
# Defaults signature: 8f19101600eba4008abf424700008ecf1490000
# Preferences signature: 1600ec6a4730d486914a000085000000
# Configuration rules: $Id: rules.cpp 32909 2007-08-17 23:07:40Z jpeach $
# Server role: Standalone
# Guest access: per-share
# NetBIOS browsing: domain master browser
# Services required: org.samba.smbd org.samba.nmbd
#

[global]
security = USER
auth methods = guest odsam
netbios name = server
workgroup = WORKGROUP
realm = SERVER.BADBOY.CO.UK
dos charset = 437
server string = server
ntlm auth = yes
lanman auth = no
max smbd processes = 100
log level = 2
use kerberos keytab = yes
realm = SERVER.BADBOY.CO.UK
map to guest = Bad User
domain master = yes
preferred master = yes
os level = 65
enable disk services = yes
enable print services = yes
wins support = no

[homes]
comment = User Home Directories
browseable = no
read only = no
create mode = 0750
guest ok = no
com.apple: show admin all volumes = no

[global]


#
# Configuration options for smbd(8), nmbd(8) and winbindd(8).
#
# This file is automatically generated, DO NOT EDIT!
#
# Defaults signature: 011b7ce002004ba48404ffe0000494b5bd30000
# Preferences signature: e002158a594a8fac4a0000000000530
# Configuration rules: $Id: rules.cpp 32909 2007-08-17 23:07:40Z jpeach $
# Server role: Standalone
# Guest access: per-share
# NetBIOS browsing: domain master browser
# Services required: org.samba.smbd org.samba.nmbd
#

[global]
security = USER
auth methods = guest odsam
netbios name = leopard
workgroup = workgroup
realm = LEOPARD.XXXX.XXXX.ORG
dos charset = 437
server string = leopard
ntlm auth = yes
lanman auth = no
max smbd processes = 100
log level = 1
use kerberos keytab = yes
realm = LEOPARD.XXXX.XXXX.ORG
map to guest = Bad User
wins server = 172.16.0.190
domain master = yes
preferred master = yes
os level = 65
enable disk services = yes
enable print services = yes
wins support = no

[homes]
comment = User Home Directories
browseable = no
read only = no
create mode = 0750
guest ok = no
com.apple: show admin all volumes = no

[global]
---------------------------------------

As you can see the file is now like my good server.

Tried to use smb to connect to shares, it failed, but I guess a server restart is in order and I cannot do that yet.

Any thoughts on the progress,or am I chasing a red herring?

SMB still broken in 10.5.8, broken kerberos seems to be the issue

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.