Identity Awareness auth and validation in separate domains?

[Paul_Hewitson]

With Identity Awareness is it possible to authenticate against one domain, and have Check Point validate the group membership for that user against another domain, thus providing them access if the same username exists in both domains?

I have a scenario where users are in Domain A. They are on workstations and also a Terminal Server in the same Domain A. They need to access resources in Domain B which is behind Check Point gateways, and there is a business requirement to identify the users by authenticating them against the isolated Domain B only (as it a secure environment).

Is this possible or could we only authenticate against Domain A in this scenario?

I guess Captive Portal could be used for the users on workstations, and have Check Point authenticate against Domain B, and the users use their Domain B accounts when authenticating?

But I don't see a method that would work for the Terminal Server, as the Identity Agent will pass on the credentials from Domain A.

Any thoughts?

Thanks

[Alessandro_Marr]

You will create a object Ldap Account Unit for this second domain and setup your identity awareness to search on both.

I am considering you are using AD query...

[Paul_Hewitson]

thanks for the reply Alessandro

The issue I have is the 2 domains are isolated from each other, there is no trust or any connectivity.

The user will have logged into Domain A on their workstation or Terminal Server. If I used AD query against Domain A & Domain B, it would pick up the user from Domain A, but it wouldn't see any login events on Domain B for that user

The business requirement is that the user is authenticated against Domain B by the Check Point somehow. The only way I can see this working is to use Captive Portal where you could you just put the Domain B credentials into the webpage.

With a terminal server the only option seems to be to use the Identity Agent which would pass the user's Domain A credentials through. 

I can't see any scenario where I can get terminal server user's to authenticate as Domain B users. Or is it possible to map the username from Domain A onto Domain B, so that the user log onto Domain A, the agent passes this to Check Point, and Check Point looks up the same username in Domain B, and we can allow access based on group membership or the fact that this account is active in Domain B.

Or is Kerberos or something involved here so this is not possible?

Not sure if I'm explaining myself very clearly.

We could have potentially used Check Point EndPoint client instead for access, for which I could specific Domain B DC for authentication, but this client isn't supported to be used from a Terminal Server. That seems to be the key issue in both cases.

[Alessandro_Marr]

Paul, when used 2 domains, AD query will bring two events of logon (1 per domain). IP of Terminal server will be diferent of their workstation and, because transparent kerberos, the identity of user will work fine.

[Paul_Hewitson]

The trouble with this solution is that the user will not have logged into Domain B (it's isolated from Domain A where the user is located), so there won't be any authentication events in that Domain for AD query to pick up. So I can only authenticate against the local Domain A.

I've labbed this up yesterday, and I think I've come to the assumption this is not possible for users on a Terminal Server, since User Identity maps a user to an IP address, and the only option for Terminal Server access is to use the agent, and the agent passes the local domain credentials of the user including the DN and the SID, so Check Point can only validate this against the local Domain A also.

I've also tried using Mobile Blade + SSL extender to provide access into the Domain B environment from terminal server users. I can have this authenticate against Domain B no problem, and run applications through SSL Extender. But as soon as I logon a 2nd TS user then they cannot run SSL extender. Which to be fair ties in with the support statement from Check Point that Remote VPN clients are not supported on multi-user servers.

Unfortunately I'm out of ideas

[Royi_Priov]

Hi Paul Hewitson‌,

If I understand correctly, although the user was not authenticated in front of domain B active directory, you still want us to authenticate and associate the user with this domain.

In most identity sources we are receiving the domain explicitly in the login information, so PDP will go and look for an account unit for this domain.

In case you want to give up the "domain A" identity completely, you can map domain a to domain b with Identity Collector alias feature. You can set up different IDC which will serve this gateway, and all authentications which will be done to domain A active directory will be sent to the GW as domain B authentications.

another option, as you have mentioned, is to use the captive portal, and specify domain B in the username (e.g. user@domainb or domainb/user - depends on the UserLoginAttr configured for this realm).

I hope this helps!

Royi.

[israelsc]

Hi @Royi_Priov 

We integrate Active Directory servers by creating LDAP units of account. Domain user authentication is done through a VPN Check Point mobile client.
When a client connects to a domain that is registered with Check Point, everything is normal. Their respective logs are generated in SmartConsole and everything is ok.

The problem arises, there are several users who have a user with the same name in one domain and registered with the same name in another subdomain.
For example:
JonhDoe@domain.com
JonhDoe@subdomain.domain.com

The priority of subdomain.domain.com is set to 1, and the priority of domain.com is set to 5.
When the user enters his username JonhDoe, he manages to access the domain.com that has lower priority, when he should access subdomain.domain.com

Is there a way that the user can choose which domain he wants to connect to from the VPN client?
For example, have the user enter JonhDoe@domain.com or
JonhDoe@subdomain.domain.com and from there it is determined which domain it will access?

We have a SMS and Firewall cluster on R80.30 version
Regards!