@zanyterp wrote: I have not seen explorer be able to prevent a user from using the address bar to attempt changing where they are connected against and apologize for that; the only behavior I have seen is the same as the SA: the user can type whatever they want in the address bar; the ACLon the server then determines if access should be allowed or not. back to the windows analogy, you can access locations that are not shared by using the hidden link on the <x> drive (e.g. C$, D$, Z$). if the user knows the full internal path, thety can type it in the address bar in explorer and connect. the server ACLs will then allow or deny access. I did not state that explorer on the client can control what you type in the address bar. I stated that the server that you want to access does. For the Windows analogy: you can only access those (default) administrative shares if you are an administrator. These are not accessible for a common user. But I'll leave it at that now. It seems I'm the only one who thinks that fiddling with an obfuscated link should be allowed by an SA. Contacting my account team to solve this and make an option out of it that seems to be considered as usefull by members here is not going to happen. ... View more

@zanyterp wrote: @minifig wrote: @df wrote: Its no different then giving a link to a file share in Windows Explorer. I can change the folder names in there, and if you don't control it with ACLs, then they will have access to everything. I've been thinking about the analogy with the file shares: - suppose you create a share on a server: \\server\share. - a normal user (not an administrator) changes the given share to \\server\users in Windows Explorer. - what would you expect from Windows to do? 1) grant access to the folder 'users' on the server with the ACL's you've set on the users folder? Even if the share \\server\users does not exist? 2) Do not grant access at all. Option 1 is what happens on the SA. Option 2 is what Windows does. Unless you have an ACL allowing it, the same will happen on the SA and deny access, as it should as you have not given permission for that new location to be seen. Explorer/Windows _does not_ prevent the user from trying to conect to a different location in the address bar. Well, the SA does allow access (see first post). And the Explorer does not prevent the user from trying to change the location, but the server who holds the share does. You absolutely cannot access a directory on a server that's not shared. The SA allows you to get to websites that you did not define as bookmarks. ... View more

@df wrote: Its no different then giving a link to a file share in Windows Explorer. I can change the folder names in there, and if you don't control it with ACLs, then they will have access to everything. I've been thinking about the analogy with the file shares: - suppose you create a share on a server: \\server\share. - a normal user (not an administrator) changes the given share to \\server\users in Windows Explorer. - what would you expect from Windows to do? 1) grant access to the folder 'users' on the server with the ACL's you've set on the users folder? Even if the share \\server\users does not exist? 2) Do not grant access at all. Option 1 is what happens on the SA. Option 2 is what Windows does. ... View more

@zanyterp wrote: The users are not changing the links; they are changing a value in their address bar. While I understand what you are saying, there is currently no way to do this. The appliance is for secure access to the network & resources you define. It is not possible to control the browser; the SA system is not a new browser but a secure access gateway. I think the idea is great, but not something it does at this time. Controlling the browser is not necessary. Controlling what is accepted in the SA is better. Maybe something for a future version then. ... View more

@stine wrote: In your example, you used =cvs. If the user shouldn't have access to this resource, you should block it. If they do have access to it, why should it matter if they bookmark it using the non-obsfucated path? If it's because you reserve the right to change the url ever two weeks and are tired of having to update your users' bookmarks, then you have a user problem. Actually: I stumbled upon the fact that a user can change this value in the address bar and get somewhere. A value that they themselves should not be able to guess. I did not expect that an SA would allow this. But I agree: blocking what they should not be able to see is best because they could get to the same place by following the links on other pages. ... View more

@df wrote: Its no different then giving a link to a file share in Windows Explorer. I can change the folder names in there, and if you don't control it with ACLs, then they will have access to everything. Actually, it is different: a link to a file share is not obfuscated and is perfectly readable; the links my users get trough the SA are not. Changing these links into something readable should not work. ... View more

@jspanitz wrote: I'd have to agree with mattspierce on this one in terms of how the SA / MAG functions. The feature you are referring to - url obfuscation - is just that - a way to mask the backend url to hide the info from the user. If the user knows a valid URL they already have the knowledge you were trying to hide. So why bother hiding it. What you were trying to accomplish by URL obfuscation actually needs to be done with Web ACLs as mattspierce stated. ACLs are the only way to keep users from going places they should not. Combining it with hiding the URLs denies an user without knowledge from gaining said knowledge. That being said, if your SA is deployed with a *.* Web ACL, I would strongly recommend you fix that as any user can get to any web resource on your network (Assuming there isn't a firewall behind the internal port of the SA). John [Edit: Posted the same time as zanyterp - sorry for the duplicate info] Well, I obfuscate the urls so they don't know what servers are behind this service. But they don't need knowledge of the actual URL to try something like 'intranet', 'mail' or even 'cvs'. I added the ACLs a few days ago. But the way I see it is that the ACL's are a workaround for a security issue in the SA. I would expect for a machine like this to not accept any fiddling with the URL when using obfuscating and not having the IVE browse bar or user added bookmarks. ... View more

@zanyterp wrote: 1) The use case defined here is not about creating links, which you as an admin can deny, but about the user modifying the URL in the address bar (which cannot be restricted). The benefit of user-created links is that users may have sites they want to use frequently that the admin has not created for them. 2) This is not the IVE browse bar but the browser used to login, that address bar. There is no control over that address bar and users can make changes there at-will. 1) I agree that changing the URL in the address bar cannot be restricted. I don't agree that users can change this link into something that actually gives them a website. When I want a user to be able to use links of their own, I would give them the IVE browse bar of the possibility to add bookmarks themselves. 2) Exactly. But as I don't give the users the IVE browse bar, I would think they can't go to links that I didn't provide for them. Apparently they can. ... View more

@mattspierce wrote: I think what you are asking would be very difficult to implement. A webserver, which is what the SA's are, don't keep state with the client. The client keeps a cookie once logged on and reminds the server of his state with each link. For what your asking to work I believe the server would have to keep track of the URL and every link in the current document a user has pulled down. That is a lot of data to keep track on the fly. The solution in the SA appliances are the Web ACL's. That is the mechansim that lets the role a user maps to get access to resources. By default I believe there are *.* access rules for the initial role. I would suggest considering removing the *.* acls. Then create resource profiles for your web pages. The profile will create an autopolicy with the ACL you need. Keeping track of what happens on the client is not really needed I think. In our case, the links themselves are scrambled (masked hostnames) so that the user does not know what server is behind the link. I suppose nobody can create such a link by themselves, but apparently they don't have to. So: 1) What's the use of being able to create a link for yourself in a non-scrambled way? 2) Why can a user go to a website they choose themselves when they don't have the IVE browse bar? ... View more