Using STAS with Backend Groups not applying policy

Hi Lars,

I would recommend you to fetch the AD User into UTM, using Agent as default authentication mode in Web Protection you force UTM to must have local User defined on UTM instead of AD because Authentication Agent will communicate with UTM for User information. That is the reason why the User and Group field are blank in the second log line where you use Agent.

Thanks

thanks for your reply! :)

ok, so you suggest to turn off agent authentication in web filter? but what auth should i use instead? Active Directory SSO?

thing is: i want to maintain the users who have "advanced" access in AD and not on the UTM. thats why i moved from AD SSO auth in web filter to STAS, because its more reliable than AD SSO, since most services / apps (firefox) dont send SSO headers by default or at all.

is there a solution where i can maintain the users in the AD group and use STAS and apply the policy in web filter based on the AD group?

kind regards
Lars

thanks for your reply! :)

ok, so you suggest to turn off agent authentication in web filter? but what auth should i use instead? Active Directory SSO?

thing is: i want to maintain the users who have "advanced" access in AD and not on the UTM. thats why i moved from AD SSO auth in web filter to STAS, because its more reliable than AD SSO, since most services / apps (firefox) dont send SSO headers by default or at all.

is there a solution where i can maintain the users in the AD group and use STAS and apply the policy in web filter based on the AD group?

kind regards
Lars

Hey, Lars.

I guess he meant fetching your AD users into UTM. That way your UTM will know every user that exists in your AD and the agent will be able to function properly. With AD SSO, the UTM does this kind of prefetch in the background, but for using with Agent as an authentication mechanism, as Sachin pointed out, the UTM needs to have a user object to query info from. 

Bottom line, keep everything the same and enable Prefetch in Definitions & Users/ Authentication Services / Advanced. You will still have your users in AD and Agent authentication should work OK. Be aware that, for a large number of users, this can consume some system resources. 

Sniped from the manual:

Prefetch Directory Users

Users from eDirectory or Active Directory can be synchronized with UTM. This will pre-create user objects on UTM such that these user objects already exist, when the user logs in. The synchronization process can run weekly or daily.

To enable prefetching, make the following settings:

Server: The drop-down list contains servers that have been created on the Servers tab. Select a server for which you want to enable prefetching.

Prefetch interval: Select an interval to prefetch users. To run the synchronization weekly, select the day of the week when synchronization should start. To run the synchronization daily, select Daily.

Prefetch time: Select a time to prefetch users.

Groups: To specify which groups should be pre-created, enter the groups here. You can use the integrated LDAP browser to select these groups.

Click Apply to save your settings.

Prefetch Now: Click this button to start prefetching immediately.

Open Prefetch Live Log: Click this button to open the prefetch live log.

Enable backend sync on login (optional): With every prefetch event, the Backend sync option of the involved users (Users & Groups > Users tab) will be set to the value defined here. If the option is enabled, the users' Backend sync option will be enabled, if the option is disabled, the users' Backend sync option will be disabled.

thank you very much for your detailed explanation! :) now i got it :D

i enabled the prefetch features for the OUs where my users at, and theyre now all locally available on the utm under users.

i switched back the web filter auth to Agent but still the policy is not evaluated and in the web filtering log theres no domain, so the only thing that has changed as far as i can tell is: all AD users now have a local UTM account...

it seems that still the web filter cannot determine the user who is in the AD Group for advanced internet access policy (which is linked to the AD Group), because there is no domain listed in the log... :(

any ideas?

Are your users being listed under Management / Definitions & Users / Client Authentication?

STAS basically fetches your user login information from your Domain Controller event viewer and maps the endpoint's IP address to a user object on UTM. That's how it works, and that's how it identifies users. If your users are not being listed as Online Users on Client Authentication, then there's something wrong with STAS or with  the communication between your UTM and STAS Collector.

Regards - Giovani

yes, users are listed. when i put the my user directly in the policy, the policy is correctly evaluated and i'm sufing with the extended profile.

so it must be something with the group, thats synced with dynamic membership in AD. seems like the UTM does not match the users in the AD group with those that are synced to the UTM by prefetch...

greetings

Lars

That's odd, for me it's working.

Would you care to post a screenshot of your backend dynamic group? Of course, obfuscate any sensitive information.

Also, take a look at aua.log and endpoint.log (User Authentication daemon and Client Authentication on WebAdmin respectively) and see if anything stands out.

Regards - Giovani

if i add my local UTM user (prefetched from AD)  in the list marked with (1) the filter works correctly, but the users in the group are not correctly evaluated.

the two logs look good. only things i found are:

in WebFilter with SSO auth the domain name is "MYDOMAIN" (netbios) [see my initial post], in the client authentication log theres the dns domain name:

2016:08:08-17:01:14  argos[6949]: [stas_event]: Received STAS package
2016:08:08-17:01:14 argos[6949]: [stas_event]: Read 405 bytes from IP 1.2.3.4:65137
2016:08:08-17:01:14 argos[6949]: [process_stas_request]: Processing STAS request TRANSPARENT_SSO_LOGON
2016:08:08-17:01:14 argos[6949]: [handle_transparent_sso_request]: Received login sso request: username MYUSER, ip_address 5.6.7.8, domain_name mydomain.mydns.name
2016:08:08-17:01:14 argos[6949]: [auth_aua_recv]: User MYUSER authenticated [REF_DefaultAdirectoryUserGroup]

one message that sounds a bit awkward is this one in the user auth log:

2016:08:08-17:01:55 firewall01 aua[3764]: id="3006" severity="info" sys="System" sub="auth" name="Child 23687 is running too long. Terminating child"
2016:08:08-17:01:55 firewall01 aua[23797]: id="3006" severity="info" sys="System" sub="auth" name="Trying 1.2.3.4 (adirectory)"
2016:08:08-17:01:56 firewall01 aua[23797]: id="3004" severity="info" sys="System" sub="auth" name="Authentication successful" srcip="1.2.3.5" host="" user="SomeUser" caller="stas" engine="adirectory"
2016:08:08-17:02:37 firewall01 aua[3764]: id="3006" severity="info" sys="System" sub="auth" name="Child 23797 is running too long. Terminating child"
2016:08:08-17:02:37 firewall01 aua[23985]: id="3006" severity="info" sys="System" sub="auth" name="Trying 1.2.3.4 (adirectory)"
2016:08:08-17:02:37 firewall01 aua[23985]: id="3004" severity="info" sys="System" sub="auth" name="Authentication successful" srcip="1.2.3.5" host="" user="SomeOtherUser" caller="stas" engine="adirectory"

==> Child 23797 is running too long. Terminating child.

sounds not that good?! could this be the reason?


<

Per your log, your user is not being mapped to your backend group, it's being mapped only to the default Active Directory Users.

[auth_aua_recv]: User MYUSER authenticated [REF_DefaultAdirectoryUserGroup]

Try creating a new group on AD, without any spaces or special characters on it and on a OU closer to your Base DN, add MYUSER directly to this group (no nested grouping) and create a new backend dynamic group, also with no spaces or special characters and try logging in again. See if anything changes. Your shoud see your user being mapped to the dynamic backend group object as below:

[auth_aua_recv]: User MYUSER authenticated [REF_somethingYourBackendGroup]

Regards - Giovani

ok, i did that and now its working! thank you! :)

but why? is special/whitespace char not supported? and can't utm evaluate nested groups? could you explain this a litte bit more? :)

thanks for your help!

Glad to help! :)

AFAIK, nested AD groups were never supported, only local nesting is. I haven't tested in a while, but I think that's still the case. Something to do with how the Linux OS (Sophos UTM is Linux based) handles the pointers needed for nested AD groups to work.

Spacing should be fine, all my groups have spaces on it and it works. Special characters, however, might throw UTM a bit haywire. It has to do with being Linux under the hood, and some issues with codepage during the LDAP queries and all.

I avoid using special characters on group names and OU's as a rule of thumb. You never know to what you'll need to interop in the future.

Now that you know that it works with a simpler named group, try tweaking your setup 'till you find something that works and still fits your naming conventions.

Regards - Giovani