Authentication on OSX via AFP / Internal LDAP

Hello,

I'm using the internal LDAP for creating accounts. All clients are Mac OSX 10.6 and
are connecting via AFP only.

Till configuring the SMB settings to force authetication, I was not able to connect to the shares as a specific user.

Is it true, that while the data transfer works over AFP, the authentication works over the SMB protocol? Shouldn'd it work directly over AFP? Please could You clear my confusion?
What other restrictions do I have on OSX clients? The manual is not clear about this!

My experiences are:
The superuser configuration doesn't work
"Force user / group" also don't work as expected - directories and files which should be
accessible to all users are not!


My basic intention is quite simple:
-I need to use AFP only
-I want to use the internal LDAP
-The access of shares is restricted via user authentication
-Every user should have all permissions to all files on available shares


Thanks,
Bernhard

Hi Bernhard,

if a AFP client connects to a AFP server, authentication and data transfer is handled by the AFP protocol. What renders Netatalk quite useless to me is the lack of EAs (Extended Attributes) and thus the lack of ACLs.

There is really no match to a real AFP server running on OS X- not to offend anyone in here, but netatalk really doesn't do the trick in a heavy duty environment.

So, what I am doing is to utilize DSS to share out iSCSI targets to my APF servers - this combo on the other hand is really sweet.

Cheers,
budy

Hi budy,

Thank You for the info!
iSCSI direct to the clients was my plan B if everything failes.
(I need to keep complexity down - I'm not a network expert :-) )

The strange thing is that the SMB settings for shares -
especially the one with user authentication vs. guest,
do affect if I can access a share as guest or as registered user via AFP!

Other SMB settings seem to have no effect.

And to update the ACLs for every share so everyone have
all permissions is not an optimal solution, especially in media production...

Thanks and kind regards,
Bernhard

Hi Bernhard,

if you plan on connecting iSCSI targets directly to the clients, then be aware of the fact, that each client must connect to one single and disctinct iSCSI target. You cannot share the iSCSI volumes between multiple clients unless your using the Xsan filesystem on those clients.

If you try to connect more than one client to any given iSCSI volume that runs HFS+, you will loose your data almost instantly by corrupting the iSCSI volume's HFS file system beyond repair through disk utility.

My solution still stands: use DSS to provide iSCSI storage to your AFP server and serve out the the shares from there. I am using Xsan in a production environment and I know what it takes to get this running smoothly. If a fast file server will do it for you, that's the way to go.

Cheers,
budy

Hi budy,

thank you for the info! Now I understand why someone needs something
like SANmp...

The problem with the recommended solution would be that if I had
a Xserve I would need too many dataports which wouldn't fit into it.

Now the direct DSS NAS solution via AFP works quite well, especially performance
at clients (80MB/sec with 1500 frames and tested with helios lan test)

The only problem is I have to give permissions manually (in DSS interface) if I want other users to work with the data they haven't produced - especially me as admin :-)
But in our edu enviroment this is ok (1 share per project; 1 user name per project team).

Kind regards,
Bernhard