To A-Bomb, and all that has the same problems….

I found out that if anything, and I mean anything does not go as planned. there is one solution that is working for me…

Delete all files in /Library/Preferences/DirectoryAccess/
Delete /Liibrary/Preferences/edu.mit.kerberos
Delete /etc/krb5.keytab

Reboot

Rebind to the AD, check if kerberos is correctly bound to the AD: run as root: klist -ke

You will get an output that should tell you that the kerberos tickets are correct.

Stop SMB

Do the “magic” script steps from this post, start SMB and now it should work.

Or at least that did the trick for me….

Have a nice weekend.

Greetings

Arnold

[b]rrathnam,[/b]

[b]I had some of those exact issues, these tips will help you:[/b]
1) the kerb password should be listed below the long string “\01\04\00\00\00\00\00\05\…”
2) put the script in /usr/bin to make the ‘command not found’ error go away

[b]I get this too every time when run: [/b](maybe this is preventing me from getting a true successful run?)
“The domain/default pair of (DirectoryService/ActiveDirectory, AD Computer Password) does not exist”
[b]
I still end up with “\00” as the new password, even with what looks like a successful run, SMB AD auth still doesn’t work[/b]

Where are Schoun & Joel when we need them 😯

This has been my experience with 10.4 Server on our new Intel XServe that I shared with an Apple engineer. Still waiting to hear a response back:

I ran into several interesting problems with SMB services on this Xserve. This configuration was based of a cleanly installed 10.4.8 Intel Xserve with all available patches applied. After binding the XServe to AD, none of my clients (Mac or PC) could connect or even browse the available default shares from the server. It would state “Cannot connect. Username or password incorrect.” It wouldn’t even bring up an authentication request to put in username or password. It simply flat out refused the connection. I did finally get it working, but it required that I ran a script against the Samba servers machine password database to append missing null data to the end of it’s password. It seems to get malformed on the Intel version of 10.4 Server. Apparently this data has something to do with the trusted computer account that this server has on the AD controller. I ran the script listed above for the secrets.tdb file.

I made it executable and ran it with the following command: changesecret $(defaults read /Library/Preferences/DirectoryService/ActiveDirectory “AD Computer Password”| /usr/bin/tr -d “< >” | /usr/bin/xxd -r -p), and then ran tdbdump against the samba secrets.tdb again. This was the output I now got on that password data string, showing the proper required null data at the end of that password:

key = “SECRETS/MACHINE_PASSWORD/MYDOMAIN”
data = “/0OAM3H57iTc69\00” <---- null data at the end now exists At this point, my Mac and Windows clients could connect, however I noticed that the first time I connected to the SMB server using my AD “psmith” account from a Windows or Mac client with no SMB shares defined on the server except for the default ones, I saw Public, Groups, Users, and a share named “psmith”, which is my AD username. I had not even set up an “psmith” share yet, but apparently the act of connecting to the kerberized SMB server using my AD “psmith” account created some sort of pseudo-share that was inaccessible. I then tested it out by creating a real SMB share named “psmith” and applied the appropriate ACE’s to it, but I could not access it with my “psmith” login. I would get an error that stated “The operation cannot be completed because one or more required items cannot be found (Error code –43). Here is the log.smbd output for this error: [2007/03/09 15:08:33, 0] /SourceCache/samba/samba-100.6/samba/source/smbd/service.c:make_connection_snum(620) '/Users/psmith' does not exist or is not a directory, when connecting to [psmith] Of course, ‘/Users/psmith’ does in fact exist under /Volumes/Admin and Users/Users/psmith. Out of curiosity, I put another user with rw permissions into the ACL for my “psmith” share. That user was able to connect and properly mount the “psmith” share without any errors or problems. The output of that connection is as follows from log.smbd: service.c:make_connection_snum(648) it-testmac (10.2.1.167) connect to service psmith initially as user MYDOMAIN\jdoe (uid=1174813369, gid=365339022) (pid 743) You can see it had no problems connecting to the same share that I tried in my previous attempt using the account “psmith”. It worked perfectly. Next I went back to the “psmith” share inside of WGM, and changed the share name “psmith” to “pjsmith” in “Windows File Settings”. I then logged back into a Mac client with my AD “psmith” account, and connected to the server via SMB. I now see the pjsmith share and can connect to it...but oddly enough the “psmith” share still exists on the dropdown menu as well, even though it’s no longer a valid share name and does not exist in /etc/smb.conf. It persists even after a restart of the Samba service, or of the entire server. It’s very strange. I don’t remember encountering these problems on the version of 10.4 Server that we have running on our G4. The problem seems to be when you access a SMB share from a Mac that is named the same as the AD login (client being binded to AD) that your using. A Windows computer seems to have no problem accessing a share that has the same name as your login account. Using an alternate account from an AD binded Mac that has any access at all to it seems to allow connections without fail. AFP shares work perfectly fine, though. Here’s a summarized list of steps taken to reproduce the issue: 1. Take a clean install of 10.4.8 Server (Intel). 2. Bind to AD domain. 3. Try to connect to the server via smb:// with a Mac or Windows client 4. Apply the above script to fix the machine password for the Samba Server 5. Verify that you can connect, and view the available default shares. Notice a new share is listed for the AD user you are currently logged in as, even though one has never been created by you. 6. Create a share named after an AD user and apply ACE’s for that user to the share. 7. Log into a Mac which is bound to the AD domain (10.4.8 client used in this test) as the AD username you named the share after. If connection fails with an Error code –43, apply a different AD user to the access list of the share you created in step 6 and try to connect again from that other account. 8. Connection to the share should work. Try renaming the share to something different than your original AD username (i.e. If the share name was psmith, and your logged in as psmith, change the share name to something different like pjsmith) 9. Try to connect again. The connection should be successful. I'm wondering if anyone else has had these same issues (other than having to run the password script on /var/db/samba/secrets.tdb.

I found out the answer to my problem from my last post. You must disable “enable virtual sharepoints” inside of Server Admin -> Windows -> Settings -> Advanced. Can’t believe it took me a week to figure this out >=0

Upgraded to 10.4.9 and pc/windows users are able to read/write.
Thanks to all of you for this valuable thread.
Thanks A-bomb and themonkman for the time taken.