This message was deleted.
# _general
s
This message was deleted.
m
I can try, I’ve done a few things in okta
r
trying to figure out a way to identify and group users behind okta policies based on internal nat ip vs egress. redoing an environment to change egress per resource group/silo is a bit of an ask
i get its a cloud idp but come on enterprise?
m
haven’t ever tried to do that, does conditional access not allow you to see that?
I’ve filtered on internal vs external IP for instance
so internal users don’t get asked for MFA for example
you can create different trusted zones per IP range and apply policy based on zone too
not sure if that helps
r
i am being told the only way is if i bind all the privates in a group that use an specific egress, that okta can't see/aware of internal. Seems odd there sin't a way to configure that
but i am getting everything on what we can/can't do second hand or worse. Thanks, i'll keep digging seems odd there isn't a way
m
Okta can totally differentiate between an internal and external IP range during the initial auth request at least. Don't know if you need to be using the agent or not for that though
r
yea i don't see an agent for multiuser
and it seems cert based so guessing nonP is a no go
not getting alot of support, thanks give me a few things least to thin it should be doable. Are you using the agent?
m
We were internally for SSO
Then we switched to the web thing that I cannot for the life of me remember
Agentless desktop sso
So that might have been how it knew
r
yea they are saying agentless doesn't know internal but i'll keep at it
m
I could be wrong! I’m not an okta expert by any means, it may have been telling me the egress IP the whole time
I don't have access to that environment anymore