[squid-users] Squid plugin sponsor

Mon Feb 14 01:21:26 UTC 2022

Thank you for your answer Elizer for all these details, but I've done 
some research to avoid soliciting the community for simple questions.

The objective is to not ask anything to the user and not to break his 
navigation with a session request.
To summarize, An SSO identification like kerberos with the following 
constraints:

 1. unknown Mac addresses
 2. DHCP IP with a short lease
 3. No Active Directory connection.

The network is in VLAN (Mac addr masked) and in DHCP with a short lease.
Even the notion of hotspot is complicated when you can't focus on a 
network attribute.
I try to find a way directly in the HTTP protocol.
This is the reason why a fake could be a solution.

But I think I'm trying to catch a chimera and we'll have to redesign the 
network architecture.

regards

Le 12/02/2022 à 06:27, Eliezer Croitoru a écrit :
>
> Hey David,
>
> The general name of this concept is SSO service.
>
> It can have single or multiple backends.
>
> The main question is how to implement the solution in the optimal way 
> possible.
> (taking into account money, coding complexity and other humane parts)
>
> You will need to authenticate the client against the main AUTH service.
>
> There is a definitive way or statistical way to implement this solution.
>
> With AD or Kerberos it’s possible to implement the solution in such a 
> way that windows will
> “transparently” authenticate to the proxy service.
>
> However you must understand that all of this requires an 
> infrastructure that will provide every piece of the setup.
>
> If your setup doesn’t contains RDP like servers then it’s possible 
> that you can authenticate a user with an IP compared
> to pinning every connection to a specific user.
>
> Also, the “cost” of non-transparent authentication is that the user 
> will be required to enter (manually or automatically)
> the username and the password.
>
> An HotSpot like setup is called “Captive Portal” and it’s a very 
> simple setup to implement with active directory.
>
> It’s also possible to implement a transparent authentication for such 
> a setup based on session tokens.
>
> You actually don’t need to create a “fake” helper for such a setup but 
> you can create one that is based on Linux.
>
> It’s an “Advanced” topic but if you do ask me it’s possible that you 
> can take this in steps.
>
> The first step would be to use a session helper that will authenticate 
> the user and will identify the user
> based on it’s IP address.
>
> If it’s a wireless setup you can use a radius based authentication ( 
> can also be implemented on a wired setup).
>
> Once you will authenticate the client transparently or in another way 
> you can limit the usage of the username to
> a specific client and with that comes a guaranteed situation that a 
> username will not be used from two sources.
>
> I don’t know about your experience but the usage of a captive portal 
> is very common In such situations.
>
> The other option is to create an agent in the client side that will 
> identify the user against the proxy/auth service
> and it will create a situation which an authorization will be acquired 
> based on some degree of authentication.
>
> In most SSO environments it’s possible that per request/domain/other 
> there is a transparent validation.
>
> In all the above scenarios which requires authentication the right way 
> to do it would be to use the proxy as
> a configured proxy compared to transparent.
>
> I believe that one thing to consider is that once you authenticate 
> against a RADIUS service you would just
> minimize the user interaction.
>
> The main point from what I understand is to actually minimize the 
> authentication steps of the client.
>
> My suggestion for you is to first try and asses the complexity of a 
> session helper, raidus and captive portal.
>
> These are steps that you will need to do in order to asses the 
> necessity of transparent SSO.
>
> Also take your time to compare how a captive portal is configured in 
> the next general products:
>
>   * Palo Alto
>   * FortiGate
>   * Untangle
>   * Others
>
> From the documentation you would see the different ways and “grades” 
> that they implement the solutions.
>
> Once you know what the market offers and their equivalent costs you 
> will probably understand what
> you want and what you can afford to invest in the development process 
> of each part of setup.
>
> All The Bests,
>
> Eliezer
>
> ----
>
> Eliezer Croitoru
>
> NgTech, Tech Support
>
> Mobile: +972-5-28704261
>
> Email: ngtech1ltd at gmail.com
>
> *From:*squid-users <squid-users-bounces at lists.squid-cache.org> *On 
> Behalf Of *David Touzeau
> *Sent:* Friday, February 11, 2022 17:03
> *To:* squid-users at lists.squid-cache.org
> *Subject:* Re: [squid-users] Squid plugin sponsor
>
> Hello
>
> Thank you but this is not the objective and this is the reason for 
> needing the "fake".
> Access to Kerberos or NTLM ports of the AD, is not possible. An LDAP 
> server would be present with accounts replication.
> The idea is to do a silent authentication without joining the AD
> We did not need the double user/password credential, only the user 
> sent by the browser is required
>
> If the user has an Active Directory session then his account is 
> automatically sent without him having to take any action.
> If the user is in a workgroup then the account sent will not be in the 
> LDAP database and will be rejected.
> I don't need to argue about the security value of this method. It 
> saves us from setting up a gas factory to make a kind of HotSpot
>
> Le 11/02/2022 à 05:55, Dieter Bloms a écrit :
>
>     Hello David,
>
>     for me it looks like you want to use kerberos authentication.
>
>     With kerberos authentication the user don't have to authenticate against
>
>     the proxy. The authentication is done in the background.
>
>     Mayb this link will help:
>
>     https://wiki.squid-cache.org/ConfigExamples/Authenticate/Kerberos
>
>     On Thu, Feb 10, David Touzeau wrote:
>
>         Hi
>
>         What we are looking for is to retrieve a "user" token without having to ask
>
>         anything from the user.
>
>         That's why we're looking at Active Directory credentials.
>
>         Once the user account is retrieved, a helper would be in charge of checking
>
>         if the user exists in the LDAP database.
>
>         This is to avoid any connection to an Active Directory
>
>         Maybe this is impossible
>
>         Le 10/02/2022 à 05:03, Amos Jeffries a écrit :
>
>             On 10/02/22 01:43, David Touzeau wrote:
>
>                 Hi
>
>                 I would like to sponsor the improvement of ntlm_fake_auth to support
>
>                 new protocols
>
>             ntlm_* helpers are specific to NTLM authentication. All LanManager (LM)
>
>             protocols should already be supported as well as currently possible.
>
>             NTLM is formally discontinued by MS and *very* inefficient.
>
>             NP: NTLMv2 with encryption does not *work* because that encryption step
>
>             requires secret keys the proxy is not able to know.
>
>                 or go further produce a new negotiate_kerberos_auth_fake
>
>             With current Squid this helper only needs to produce an "OK" response
>
>             regardless of the input. The basic_auth_fake does that.
>
>             Amos
>
>             _______________________________________________
>
>             squid-users mailing list
>
>             squid-users at lists.squid-cache.org
>
>             http://lists.squid-cache.org/listinfo/squid-users
>
>         _______________________________________________
>
>         squid-users mailing list
>
>         squid-users at lists.squid-cache.org
>
>         http://lists.squid-cache.org/listinfo/squid-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20220214/200bc232/attachment-0001.htm>