Re: [squid-users] Squid plugin sponsor

2022-02-14 Thread David Touzeau

Eliezer,

First of all, thank you for twisting your brain at our request.
I know your skills and your time is very valuable.

HotSpot+Cookies can be interesting but it has a constraint that 
kerberos/NTLM SSO fixes:


1)  Redirecting connections to a HotSpot requires Squid to be able to 
forward the redirection.
When using SSL sites without MAN-IN-THE-MIDDLE, we fall into structural 
issues.


2)  Even if this problem can be circumvented, it is necessary for the 
user to identify himself on the Splash Screen to understand who he is.

While this user is already identified with his Windows session.


Forget about NTLMv2 which does not provide the "Fake" anymore
The advantage of fake_ntlm is that when Squid performs its 407, 
naturally the browser sends its windows session username whether it is 
connected to an Active Directory or not.


This is what we want to catch in the end.

The HotSpot way is a half-solution. It circumvents the limit of 
identification but adds new network constraints you mention.


The dream is a plugin that forces Squid to generate a 407, asks to 
browsers "Give me your user account whatever it is" and allows access in 
any case to place the user=xxx switch for the next processing.


It almost looks like the "ident" method
http://www.squid-cache.org/Misc/ident.html
Without having to install a piece of software and a listening port on 
all the computers in the network


Le 14/02/2022 à 19:50, Eliezer Croitoru a écrit :


Hey David,

Transparent authentication using Kerberos can only be used with a 
directory service.


There are couple ways to authenticate…

You can use an “automatic” hotspot website that will use cookies to 
authenticate the client once in a very long time.


If the client request is not recognized or the client is not 
recognized for any reason it’s reasonable to redirect him into a 
captive portal.


I can try to work on a demo but I need to know more details about the 
network structure and to verify what is possible and not.


Every device ie Switch and router or AP etc should be mentioned to 
understand the scenario.


While you assume it’s a chimera I still believe it’s just a three 
heads Kerberos which… was proved to exists… in the movies and in the 
virtual world.


Eliezer



Eliezer Croitoru

NgTech, Tech Support

Mobile: +972-5-28704261

Email: ngtech1...@gmail.com

*From:*David Touzeau 
*Sent:* Monday, February 14, 2022 03:21
*To:* Eliezer Croitoru 
*Cc:* squid-users@lists.squid-cache.org
*Subject:* Re: [squid-users] Squid plugin sponsor


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 wo

Re: [squid-users] Squid plugin sponsor

2022-02-14 Thread Eliezer Croitoru
Hey David,

 

Transparent authentication using Kerberos can only be used with a directory 
service.

There are couple ways to authenticate…

You can use an “automatic” hotspot website that will use cookies to 
authenticate the client once in a very long time.

If the client request is not recognized or the client is not recognized for any 
reason it’s reasonable to redirect him into a captive portal.

I can try to work on a demo but I need to know more details about the network 
structure and to verify what is possible and not.

Every device ie Switch and router or AP etc should be mentioned to understand 
the scenario.

While you assume it’s a chimera I still believe it’s just a three heads 
Kerberos which… was proved to exists… in the movies and in the virtual world.

 

Eliezer 

 



Eliezer Croitoru

NgTech, Tech Support

Mobile: +972-5-28704261

Email: ngtech1...@gmail.com <mailto:ngtech1...@gmail.com> 

 

From: David Touzeau  
Sent: Monday, February 14, 2022 03:21
To: Eliezer Croitoru 
Cc: squid-users@lists.squid-cache.org
Subject: Re: [squid-users] Squid plugin sponsor

 


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 

Re: [squid-users] Squid plugin sponsor

2022-02-13 Thread David Touzeau


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: ngtech1...@gmail.com

*From:*squid-users  *On 
Behalf Of *David Touzeau

*Sent:* Friday, February 11, 2022 17:03
*To:* squid-users@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

Re: [squid-users] Squid plugin sponsor

2022-02-11 Thread Eliezer Croitoru
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: ngtech1...@gmail.com <mailto:ngtech1...@gmail.com> 

 

From: squid-users  On Behalf Of 
David Touzeau
Sent: Friday, February 11, 2022 17:03
To: squid-users@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 "

Re: [squid-users] Squid plugin sponsor

2022-02-11 Thread David Touzeau

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@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users


___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] Squid plugin sponsor

2022-02-10 Thread Eliezer Croitoru
Hey Dieter,

I have tried to use the mentioned wiki document to try and re-create a LAB
with AD 2012-2019.
I got stuck with a setup that is not usable in the terms of transparent
authentication.
I have tried on the next OS:
* Debian 10/11
* Ubuntu 18.04/20.04
* CentOS 7/8
* Oracle Enterprise Linux 7/8

I would be happy to try and re-create the lab here and to make sure that
there will be a well documented configuration guide.
If there is a good tutorial or guide I would be happy to try and verify if
it works in my lab.

Thanks,
Eliezer


Eliezer Croitoru
NgTech, Tech Support
Mobile: +972-5-28704261
Email: ngtech1...@gmail.com

-Original Message-
From: squid-users  On Behalf Of
Dieter Bloms
Sent: Friday, February 11, 2022 06:56
To: squid-users@lists.squid-cache.org
Subject: Re: [squid-users] Squid plugin sponsor

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@lists.squid-cache.org
> > http://lists.squid-cache.org/listinfo/squid-users

> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users


-- 
Gruß

  Dieter

--
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
>From field.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] Squid plugin sponsor

2022-02-10 Thread David Touzeau

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@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] Squid plugin sponsor

2022-02-09 Thread Amos Jeffries

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@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users