User's home directory

[muttbarker_]

Well the SA box lets you choose one server for authentication and a second server for authorization. This is done from the Realm general page - The Directory/Attribute server maps to your authorization server.

So if you are using AD for the authentication part then simply define a second AA server - point back to your AD server but define it as an LDAP and use it instead on the realm setup.

[rdit_]

ah i understand, thanks fot that tipp. but the problem is that the user has to sign-in twice then, right? first he needs to authenticate via RSA and then he has to login with his ldap credentials, doesn't he?

dont know if i could solve that with SSO, any idea on that?

thanks for your answer!

[muttbarker_]

Are you using a seperate server for your RSA? Or do you have a single back end AD server?

[rdit_]

theres a seperate RSA-server for authentication. ldap is only configured for other realms for securemeeting-purposes and these realms are only accessable from the internal LAN (restricted by source ip filter). if a user wants to access his userhome via a fileshare-bookmark he needs to fill in his ldap credentials first. so it would be great to have something like SSO in some way or just any opportunity to use the ldap-variables, to map every user his direct homefolder and not the root-folder with all userhome-directories in it where he needs to search for his own folder.

Message Edited by rdit on 08-05-2009 08:24 AM

Message Edited by rdit on 08-05-2009 08:25 AM

[danr_]

I discovered the problem. My home dir path is \\server\home\<username>. I have discovered for some reason Juniper is failing to connect the user because it is trying to get 'list' access to \\server\home, why I don't know since no user ever goes there. I kept getting an error 13 in the user log.

So I changed the rights on \home to allow 'list' rights and now the user's file share link works.

Thank you for replying. I think this file share problem is unique in that is involves a NetApp filer running cifs, not a windows file server.

[SonicBoom_]

you can also personalize it a little more by pulling the users name from AD using \\<userAttr.homeDirectory> and changing the bookmark to read <userattr.cn>'s Documents, now when a user logs in it will say John Doe's Documents

[Integralis_FR_]

I've been setting dual authentication realms just for SSO:

1st server is the AD/LDAP server

2nd server is the RSA server

I use the username from the 1st server as the user for 2nd server, changing the sign-in page to ask for user/password/token

The main advantage is that once the user is logged, you can replay its credentials during the session (files, OWA, ...)

Hope this helps !

[Lilja_]

Hi Guys,

Bumping this thread as it seemed appropriate..

I have successfully created a bookmark to users homedir with the <userAttr.homeDirectory> attribute but cannot get it to work (access denied) with the ACL automatically created.

It works fine if an additional file ACL is created allowing \\* (the default ACL).

So my question is:

How should the ACL look like when using <userAttr.homeDirectory> and when users directorys are located on different DFS-shares?

/Lilja

[SonicBoom_]

mine simply looks like this \\<userAttr.homeDirectory>\

and \\<userAttr.homeDirectory>\*\* is what is automatically created for access control.

now if they have directories on different servers then you need to point to those as well with a role mapping to it.

for example accounting might go to \\server\directory\ with a role stating if group is accounting assign accounting bookmark

[zanyterp_]

Depending on the configuration on the attribute, the different DFS servers will be needed to be defined as allowed as well. If the attribute points to the specific DFS server, that should be ok; however, if it points to an alias that redirects, those redirected servers will need to be added manually.

For example, if \\<userAttr.homeDirectory> resolves to \\myserver\myuser, then that should be fine as long as myserver is the only server you are connecting to; if, however, myserver is an alias and the data actually resides on \\dfs2\myuser, then you will need to add both to the ACL list and so on.