About LordRouter

One drawback with captive portal is that you must use a browser (well for obvious reasons 😃 to identify yourself even if the actual protocol being used might be different (like if you use FTP or such to access this restricted zone). Also user-id in PA is global meaning (as I understand it) the PA device doesnt care on how it learned which user it is as long as it knows which user the srcip belongs to. This can however be workaround if the user/pass identification is a different user in the AD compared to the user normally authenticated against the AD. I mean regular access (which user-ids to allow) looks at AD\Users, while this enhanced security access look at AD\RestrictedUsers (where the useraccount in AD\Users is different from AD\RestrictedUsers) or for that matter from a different AD. The problem here might be that regular access might be smartcard based where accessing your golden eggs suddently only needs a basic user/pass auth (even if the pass is OTP based like secureid or such). So in your case I guess you want first the regular access and only if this passes then add the restricted access (which use user/pass(OTP or such))? Cant this be done in the AD itself? Because then the PA would only have to look at the proper AD-group to grant access to the more sensitive areas. Im thinking that a regular user first login with their smartcard or whatever. Then when they are logged in they can do a second auth to the AD using their OTP. The problem here might be that the PA currently only maps one user per ip. So as soon as the second useraccount (part of AD\RestrictedUsers) is authed the PA will no longer allow access to the regular services which checked for AD\Users. Or if this can be done at the loginpart of the workstation, if the user adds OTP info the user is identified for RestrictedUsers group otherwise it will just be identified for Users group. ... View more