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.
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!
Are you using a seperate server for your RSA? Or do you have a single back end AD server?
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.
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 !
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?
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
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.