[Resolvido] Captive Portal com FreeRadius Autenticando em Openldap



  • Bom dia.
    Talvez alguem possa me dar uma luz do que possa ser.
    Tenho que fazer o captive portal utilizar a base de usuarios do freeradius que esta autenticando em base openldap.
    O problema que quando uma maquina estação clica no navegador vejo a tela de autenicação do captive portal pedindo usuário. Informo o usuario e senha ai aparece uma outra tela de autenticação do captive portal informando que o servidor Radiuns não responde.
    A mensagem é esta abaixo.
    Error sending request: No valid RADIUS responses received.





  • Completando.
    Rodei o comando radiusd -X no modo terminal e notei que ele traz a seguinte mensagem de falha

    listen {
    type = "auth"
    ipaddr = 10.9.9.5
    port = 1812
    Failed binding to authentication address 10.9.9.5 port 1812: Address already in use
    /usr/local/etc/raddb/radiusd.conf[36]: Error binding to port for 10.9.9.5 port 1812



  • @gilmarcabral:

    Completando.
    Rodei o comando radiusd -X no modo terminal e notei que ele traz a seguinte mensagem de falha

    listen {
    type = "auth"
    ipaddr = 10.9.9.5
    port = 1812
    Failed binding to authentication address 10.9.9.5 port 1812: Address already in use
    /usr/local/etc/raddb/radiusd.conf[36]: Error binding to port for 10.9.9.5 port 1812

    First stop freeradius service on GUI
    or

    kilall -9 radiusd
    

    Second

    radiusd -X
    


  • Fiz conforme você me informou.

    radiusd: #### Opening IP addresses and Ports ####
    listen {
    type = "auth"
    ipaddr = 10.9.9.5
    port = 1812
    }
    Listening on authentication address 10.9.9.5 port 1812
    Listening on proxy address 10.9.9.5 port 1814
    Ready to process requests.



  • Ready to process requests.
    Ignoring request to authentication address 10.9.9.5 port 1812 from unknown client 10.9.9.5 port 12874
    Ready to process requests.
    Ignoring request to authentication address 10.9.9.5 port 1812 from unknown client 10.9.9.5 port 12874
    Ready to process requests.
    Ignoring request to authentication address 10.9.9.5 port 1812 from unknown client 10.9.9.5 port 61689
    Ready to process requests.
    Ignoring request to authentication address 10.9.9.5 port 1812 from unknown client 10.9.9.5 port 61689
    Ready to process requests.

    Quando tento logar apresenta esta mensagem no terminal



  • The IP 10.9.9.5 is not in your "NAS/Clients" on freeradius.
    Add IP 10.9.9.5 in "NAS/Clients" with correct password.



  • Agora estou recebendo esta mensagem abaixo.
    rad_recv: Access-Request packet from host 10.9.9.5 port 33478, id=34, length=135
    NAS-IP-Address = 10.9.9.5
    NAS-Identifier = "murici.agrovale.com.br"
    User-Name = "gilmar_20601"
    User-Password = "\215:\177\024K\374\343\273\342\004\026\345F\021\351\245"
    Service-Type = Login-User
    NAS-Port-Type = Ethernet
    NAS-Port = 10
    Framed-IP-Address = 10.9.9.10
    Called-Station-Id = "10.9.9.5"
    Calling-Station-Id = "00:1b:24:fb:6c:d7"

    Executing section authorize from file /usr/local/etc/raddb/sites-enabled/default

    +- entering group authorize {…}
    ++[preprocess] returns ok
    ++[chap] returns noop
    ++[mschap] returns noop
    ++[digest] returns noop
    [suffix] No '@' in User-Name = "gilmar_20601", skipping NULL due to config.
    ++[suffix] returns noop
    [ntdomain] No '' in User-Name = "gilmar_20601", skipping NULL due to config.
    ++[ntdomain] returns noop
    [eap] No EAP-Message, not doing EAP
    ++[eap] returns noop
    ++[files] returns noop
    ++- entering policy redundant {…}
    [ldap] performing user authorization for gilmar_20601
    [ldap] expand: %{Stripped-User-Name} ->
    [ldap] … expanding second conditional
    [ldap] expand: %{User-Name} -> gilmar_20601
    [ldap] expand: (uid=%{%{Stripped-User-Name}:-%{User-Name}}) -> (uid=gilmar_20601)
    [ldap] expand: dc=agrovale,dc=com,dc=br -> dc=agrovale,dc=com,dc=br
      [ldap] ldap_get_conn: Checking Id: 0
      [ldap] ldap_get_conn: Got Id: 0
      [ldap] performing search in dc=agrovale,dc=com,dc=br, with filter (uid=gilmar_20601)
    [ldap] looking for check items in directory…
      [ldap] userPassword -> Password-With-Header == "{SSHA}9/jyPvDceGSRIDfPgPJvujVp2AVIUTRN"
      [ldap] sambaNtPassword -> NT-Password == 0x3731333730413042323636453441443241303139383836323034303139353944
      [ldap] sambaLmPassword -> LM-Password == 0x3933363541454439384337303434443632354144334238334641363632374337
    [ldap] looking for reply items in directory…
    [ldap] Setting Auth-Type = LDAP
    [ldap] user gilmar_20601 authorized to use remote access
      [ldap] ldap_release_conn: Release Id: 0
    +++[ldap] returns ok
    ++- policy redundant returns ok
    rlm_counter: Entering module authorize code
    rlm_counter: Could not find Check item value pair
    ++[daily] returns noop
    rlm_counter: Entering module authorize code
    rlm_counter: Could not find Check item value pair
    ++[weekly] returns noop
    rlm_counter: Entering module authorize code
    rlm_counter: Could not find Check item value pair
    ++[monthly] returns noop
    rlm_counter: Entering module authorize code
    rlm_counter: Could not find Check item value pair
    ++[forever] returns noop
    rlm_checkval: Item Name: Calling-Station-Id, Value: 00:1b:24:fb:6c:d7
    rlm_checkval: Could not find attribute named Calling-Station-Id in check pairs
    ++[checkval] returns notfound
    ++[expiration] returns noop
    ++[logintime] returns noop
    [pap] Normalizing NT-Password from hex encoding
    [pap] Normalizing LM-Password from hex encoding
    [pap] Normalizing SSHA1-Password from base64 encoding
    [pap] WARNING: Auth-Type already set.  Not setting to PAP
    ++[pap] returns noop
    Found Auth-Type = LDAP

    Executing group from file /usr/local/etc/raddb/sites-enabled/default

    +- entering group LDAP {…}
    [ldap] login attempt by "gilmar_20601" with password "?:?K����??�F?��"
    [ldap] user DN: uid=gilmar_20601,ou=Usuarios,dc=agrovale,dc=com,dc=br
      [ldap] (re)connect to 192.168.1.39:389, authentication 1
      [ldap] setting TLS CACert File to /usr/local/etc/raddb/certs/ca_ldap1_cert.pem
      [ldap] setting TLS CACert Directory to /usr/local/etc/raddb/certs/
      [ldap] setting TLS Require Cert to never
      [ldap] setting TLS Cert File to /usr/local/etc/raddb/certs/radius_ldap1_cert.crt
      [ldap] setting TLS Key File to /usr/local/etc/raddb/certs/radius_ldap1_cert.key
      [ldap] setting TLS Key File to /usr/local/etc/raddb/certs/random
      [ldap] bind as uid=gilmar_20601,ou=Usuarios,dc=agrovale,dc=com,dc=br/?:?K����??�F?�� to 192.168.1.39:389
      [ldap] waiting for bind result …
      [ldap] Bind failed with invalid credentials
    ++[ldap] returns reject
    Failed to authenticate the user.
    expand:  ->
    Login incorrect (  [ldap] Bind as user failed): [gilmar_20601] (from client pfsense port 10 cli 00:1b:24:fb:6c:d7)
      WARNING: Unprintable characters in the password.  Double-check the shared secret on the server and the NAS!
    Using Post-Auth-Type Reject

    Executing group from file /usr/local/etc/raddb/sites-enabled/default

    +- entering group REJECT {…}
    [attr_filter.access_reject] expand: %{User-Name} -> gilmar_20601
    attr_filter: Matched entry DEFAULT at line 11
    ++[attr_filter.access_reject] returns updated
    Delaying reject of request 2 for 1 seconds
    Going to the next request
    Waking up in 0.9 seconds.
    Sending delayed reject for request 2
    Sending Access-Reject of id 34 to 10.9.9.5 port 33478
    Waking up in 4.9 seconds.
    rad_recv: Access-Request packet from host 10.9.9.5 port 33478, id=34, length=135
    Sending duplicate reply to client pfsense port 33478 - ID: 34
    Sending Access-Reject of id 34 to 10.9.9.5 port 33478
    Waking up in 4.9 seconds.
    Cleaning up request 2 ID 34 with timestamp +113
    Ready to process requests.



  • Descobri o motivo deste erro.
    Era porque tava faltando a senha de autenticação do captive portal autenticar no freeradiuns.
    Agora esta validando porem quando valida o usuario e grupo ai não ta navegando na internet.
    Da pagina não pode ser exibida.



  • The hosts must use pfsense DNS Forwarder as DNS server or CP will not work/redirect.



  • Tenho um servidor bind interno como cache na rede lan.
    O host atras da rede wireless esta setado para usar o servidor dns que esta na rede lan em ambiente debian com bind.
    Este host atras da rede wireless pinga em todas maquinas da lan.
    Penso que o problema não seja acesso ao dns.



  • Surgiu uma duvida comigo.
    O Captive Portal com FreeRadius não deixa o acesso bloqueado ate que o usuário consiga fazer autenticação via navegador?
    Testei aqui e notei que se eu não fizer autenticação e tentar acessar o ambiente de rede que esta na lan eu consigo.
    Para mim o captive portal com freeradius só deixava isso ocorrer caso tive-se sucesso no login.
    Agradeço novamente



  • @gilmarcabral:

    Testei aqui e notei que se eu não fizer autenticação e tentar acessar o ambiente de rede que esta na lan eu consigo.

    veja em que regras do ipfw o trafego está autorizado.

    ipfw show e ipfw zero via console/ssh podem ajudar no diagnostico.



  • Descobri o motivo.
    E devido que após a autenticação no captive portal ele fica disponivel ate 30 minutos de inativididade para depois expirar a conexão.
    Ai como tavo logando e depois fechando o captive portal a conexão irá ficar valendo ate 30 minutos.
    Então diminiu este tempo
    Mas agora após a validadeção do captive portal ele passa mas não consigo navegar na web da como pagina não pode ser exibida.
    Estou utilizando o captive portal + freeradiuns + Proxy autenticado squid (squidGuard) + bind em servidor debian.
    Obs. na reda lan eu estou usando o squid + squidguard e a regra para a interface wireless esta any para tudo.
    Agradeço



  • Eu utilizo proxy autenticado com o squidguard.
    O problema que esta ocorrendo que quando abro o navegador ele não aparece a tela de login do captive portal, mas se eu for no navegador e digitar o IP + porta 8080 ele aparece a tela de login.
    Estou com o ip do proxy setado nas configurações do navegador pois utilizo proxy autenticado.
    Testei sem o proxy setado e acontece a mesma coisa.



  • existe uma opção no squid para caso voce utilize captive portal junto , habilite essa opção



  • Isso mesmo.
    Estava habilitado, então desabilitei novamente e habilitei e deu certo.
    Porem agora estou com um outro problema.
    Tenho um atalho para o sistema, este funciona pelo navegador então tenho um atalho na area de trabalho apontando para este endereço que e: http://192.168.1.32/sief ou http://sief.agrovale.com.br/sief.
    Pois bem quando o usuario autenticar no captive portal o mesmo direciona para o squidGuard Autenticado porem ele da um erro conforme a imagem anexo.
    Parece que o problema esta na barra após o endereço.




  • você tem alguma outra regra de reescrita de url? a imagem de erro parece mostrar o ip interno colado no nome da pasta sief.



  • Estou achando estranho na imagem a ultima mensagem:
    URL: http://192.168.1.32sief/

    Sendo que meu link esta assim: 192.168.1.32/sief.
    Parece que ele ta comendo a barra /.



  • Pois é, mas na URL do screenshot esta OK.

    Você não consegue deixar o acesso interno sem proxy via wpad ou gpo?



  • Bom dia.
    Obrigado.
    Sobre a URL, ele não deveria ter uma barra depois do ip?
    Da maneira que ele esta apresentando ai esta emendado o IP + o nome do sistema.

    Sobre o proxy posso tentar via wpad pois sem proxy não da certo pois utilizo proxy autenticado com o squidguard.



  • @gilmarcabral:

    Sobre o proxy posso tentar via wpad pois sem proxy não da certo pois utilizo proxy autenticado com o squidguard.

    Para evitar gargalo e criar um ponto único de falha, qualquer acesso http/https interno deve ficar fora do proxy.



  • Certo.
    Isso já ocorre.
    Tenho a seguinte regra no Custom Settings do squid
    acl SITES_NO_PROXY url_regex "/var/db/squidGuard/SITES_NO_PROXY/domains";
    http_access allow SITES_NO_PROXY;redirect_children 3 redirect_program /usr/local/bin/squidGuard -c /usr/local/etc/squidGuard/squidGuard.conf;
    redirect_program /usr/local/bin/squidGuard -c /usr/local/etc/squidGuard/squidGuard.conf;redirector_bypass

    Neste arquivo domains tenho o IP 192.168.1.32 para não passar pelo proxy.
    Ate na lan eu digitar o ip 192.168.1.32/sief no navegador o mesmo não pede autenticação.



  • Gilmar,

    Mas de qualquer forma você esta enviando a requisição para o squid.

    Falo de alterar o wpad ou a gpo para não enviar trafego interno para o proxy.

    Entende a diferença?



  • Eu coloquei no firefox sem proxy para sief.agrovale.com.br e 192.168.1.32 e ocorre o mesmo problema.
    Penso que seria a mesma coisa que colocar no wpad.



  • Se o IP cadastrado esta na mesma faixa de rede da estação de trabalho, o acesso não deveria passar pelo proxy.

    Tentou fechar e abrir o browser depois da alteração da configuração? Faça o teste sem o wpad.



  • No caso a rede da estação é 10.9.9.0/24 esta rede acessa a rede 192.168.1.0/24 que é onde esta o servidor 192.168.1.32.



  • Alguma chance do proxy estar com modo transparente habilitado?



  • Bom dia.
    Estou com o Proxy Setado no navegador e o mesmo esta autenticando em base openldap.



  • Bom dia.
    Pelo meus testes o problema ocorre porque o squidGuard não esta conseguindo liberar conexão vinda de uma outra lan no meu caso 10.9.9.0.
    Minha lan é 192.168.1.0 e o squidguard aceita perfeitamente.
    Já quando o trafego vem da rede 10.9.9.0 que e direcionado para o proxy ai o squidguard não esta conseguindo tratar nas acl e cai no grupo não defenido.



  • Aparece algo no log do squid(access e cache.log)?

    Conferiu se esta outra faixa está cadastrada no squid como ips autorizados?



  • Pelo que descobri e algo relacionado do captive portal direcionando a URL para o squid que após o dominio o mesmo esta retirando a /.
    Fiz um teste liberando o endereço.
    http://www.linkteck.com.br/site/produtos

    Ai ele direcionou para uma url como inexistente pois na barra de endereço ficou da seguinte forma.
    http://www.linkteck.com.brsite/produtos



  • Boa tarde.
    Realmente o problema era a falta da barra.
    No script index.php do captive portal localizado em /usr/local/captiveportal estava sem a barra entra a variavel orig_host e orig_request.
    Estaquei em negrito a alteração do arquivo captive portal.

    if (isset($config['captiveportal']['httpslogin']))
           header("Location: https://{$ourhostname}/index.php?redirurl=" . urlencode("http://{$orig_host}/{$orig_request}"));
       else
           header("Location: http://{$ourhostname}/index.php?redirurl=" . urlencode("http://{$orig_host}/{$orig_request}"));



  • Gilmar,

    Esta atualização resolveu somente o erro do display ou resolveu o problema de acesso?

    EDIT

    Este erro já foi corrigido no código da 2.0.3 pelo ermal no dia 03/01  :)

    att,
    Marcello Coutinho



  • Bom dia.
    Eu já tinha resolvido o problema de acesso.
    O problema que estava tendo era porque o as url como sief.agrovale.com.br/sief caia no squidGuard como negado.
    E lembrando que já tinha regra no squidguard liberando esta url.
    Ai notei que isso ocorreia com todas urls que tinha a barra.
    Esta versão 2.0.3 que você informou que corrigiu este problema já saiu?
    Pois meu pfsense esta na versão 2.0.2 e no status de versão ele informa que estou com a versão mais nova.



  • @gilmarcabral:

    Esta versão 2.0.3 que você informou que corrigiu este problema já saiu?

    Ainda não. Está na pre-release. Alguns bugs foram corrigidos mas o core team ainda esta esperando alguns feedbacks sobre o captive portal para finalizar a versão.



  • Ahh tá.
    Só encontrei este bug por enquanto relacionado ao captive portal.
    Mas muito obrigado pela sua ajuda.


Locked