Sharepoints and OD/AD

[Marci]

Have now worked thru Pg371 to 374 of Mac OSX Directory Services 10.5 training book, which covers the kerberizing of services as per your previous posts, so that's all ok, and have also ensured the the AD plugin and Samba services are using the same AD Computer Password...

 

No change. SSO works fine if you go thru Finder > Go > Connect to Server (and use the FQDN of the server in question), however, it basically authenticates you as a guest... doesn't show the shares that the user in question actually has permission to access.

Edited February 12, 2009 by Marci

[HodgeHi]

Sorry i didn't manage to get back to you. I will have a look at my server config for you when i get back to work although i am unsure as to when that is going to be since i may be working from home for most of the week off.

 

What happens if you use "afp://AD_username:password@FQDN_of_OSXserver/sharename"

 

You know to replace the details above with your own. Also i found that the share names are also case sensitive.

 

You could also log on as an AD user, get a kerberos ticket from the authentication server and try "afp://;AUTH=Client%20Krb%20v2@myserver/myVolume"

 

Again replace myserver/myvolume with your own. The above should try kerberos auth for mounting the AFP share. Not sure if this works in the Finder though.

 

You could also try the IP address of the server instead of the FQDN. This may help to remove any doubt over DNS.

[Marci]

Tried all the above... still no joy. Effectively lets AD users in, but only shows them shares available to "Guest".

[HodgeHi]

Can't remember if i asked this already. Is guest disabled on the shares themselves?

 

I have effectively removed posix permissions on my shares by removing access to the users listed. Admin no access, group no access, everyone no access. I have then set the administrator ACL up for full control on the share and then propagated the permissions. I also did the same for the AD groups that the staff and Pupils are in.

 

can you access the shares using an administrator user?

[Marci]

Not had chance to continue working on this for a while, but will hopefully get round to looking at it tomorro so will let u know...

[Marci]

Is guest disabled on the shares themselves?

Yup

 

I have effectively removed posix permissions on my shares by removing access to the users listed. Admin no access, group no access, everyone no access. I have then set the administrator ACL up for full control on the share and then propagated the permissions. I also did the same for the AD groups that the staff and Pupils are in.

 

Just done that... still same issue.

 

can you access the shares using an administrator user?

Yep - admin user can access everything fine...

 

Here's how I've got it in Server Admin:

 

Sharepoint:

Nothing ticked at all.

 

Protocol Options...

AFP:

Share this item using AFP.

Custom AFP Name: Music

 

SMB:

Share item using SMB

Custom SMB Name: Music

Enable oplocks

Enable strict locking

Inherit Permissions from Parent

 

FTP:

n/a

 

NFS:

n/a

 

Permissions...

ACL:

HORBURY\domain admins > Full Control

HORBURY\domain users > Read & Write

 

POSIX:

mcoyles2 > None

staff > None

Others > None

 

 

ServerAdmin Settings...

Access:

For all services > Allow all users and groups

 

 

AFP & SMB Services definitely running.

Edited April 7, 2009 by Marci

[Marci]

Finally sussed all this out....

 

1 - The kerberosPrinicipal was corrupt in com.apple.AppleFileServer.plist - solution:

stop afp

terminal

cd /Library/Preferences

sudo pico com.apple.AppleFileServer.plist

replace ridiculously long SHA1 hash beside "afpserver/" with fqdn@DN as follows

kerberosPrincipal
afpserver/[email protected]

ctrl-o (save) ctrl-x (quit)

start afp

 

Immediately when connecting via AFP with AD credentials, I was presented with a list of available mountpoints to choose from... however, it only appeared to want to show me 2, despite me being a SystemAdmin and should've therefore been able to see at least 8 that I'd created. This was because...

 

2 - The idiots that installed our X-Server formatted the Raid Array as an admin user, but not root. I noticed the 2 sharepoints it was showing me both happened to be owned by root:admin, and were both on the main HD nor the raid array. As soon as I ran chown root:admin on /Volumes/ServerRaid/, all afp shares started working, with ACLs functioning properly based on AD Groups. A bit more chown -R and chmod -R action to tidy things up a bit, and all is now working perfectly. It would appear that ServerAdmin can't set the ACLs properly if the drive you're working on (or it's mountpoint to be precise) isn't owned by root. They'd created a separate admin user and done everything under that user's credentials. Wandered thru all the sharepoints that weren't showing up and chowned them to root:admin, et voila. All accessible, and reflecting the permissions as set in the ACLs for that sharepoint. Even accessible from Windows clients, with ACLs STILL working...

 

Moral of this story? Never trust an AppleCertifiedCompany to get it right when they come and install a network for you. 50% of what they'd done was done incorrectly (managed settings for clients simply didn't work.... it was obvious they'd set them, but when those settings didn't actually pass down to the clients, they didn't bother investigating further... same goes for the sharepoints they created that never worked from day one... and ditto for the DNS issues we originally had too). I've essentially undone everything they did and had to do it all again from scratch myself, finding the cause of the errors as I went along. Only cost us 8 months of functionality

 

Upside to all this? Having never touched a Mac prior to this debacle, I'm now quite proficient in it all... fortunately I had a great deal of FreeBSD experience under my belt from managing webservers which helped tremendously...

 

Next mission: get imaging & netboot to work properly... they'd set the Netboot images to run off the main (small HD) and when I attempted to reimage my final tweaked-properly client, it filled the drive. Attempts to shift it failed everytime (I'm guessing because the share points weren't working correctly due to point 2 above)... so will be attacking that tomorrow...

 

Ta fer all the cross-referencing of settings HodgeHi! It's only from comparing not-working vs working that I've managed to get this thing sorted so would've been stuffed without ya...

Edited May 27, 2009 by Marci

[Marci]

Additional bonus this morning: the shares on the x-server are all accessible from Windows clients, and the ACLs defined by the X-Server still work perfectly for PC clients. Me's a happy camper!