Tacacs + с двухфакторной аутентификацией Google PAM?

Я работаю над сервером tacacs + для своей сети университетского городка, и мне было интересно, как я могу настроить сервер tacacs + для связи с PAM, использующим двухфакторную аутентификацию Google. Я немного погуглил, нашел полезную информацию, но не нашел четкой «дорожной карты», и многие шаги в лучшем случае кажутся нечеткими. У меня сейчас работает тестовый стенд Ubuntu tacacs + без настроенных коммутаторов или маршрутизаторов.

Кто-нибудь делал что-то подобное? Я нашел здесь относительно хорошее руководство в цепочке электронной почты redhat: https://www.redhat.com/archives/pam-list/2014-March/msg00008.html

Я не знаю, куда идти дальше и как работает эта система. Есть ли какие-нибудь примеры, которым я могу следовать, или есть какие-нибудь предложения? Мне кажется, что сейчас я нахожусь в режиме проб и ошибок.

РЕДАКТИРОВАТЬ: В частности, прямо сейчас я смотрю на примеры файлов конфигурации PAM в /etc/pam.d/(tac_plus? Как бы это ни называлось) и я не уверен, что именно туда нужно. Это что-то вроде аутентификатора Google или tacacs +? Мой пример выглядит примерно как код, опубликованный ниже, но я не уверен, что здесь происходит:

auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        sufficient    pam_ldap.so use_first_pass
auth        required      pam_deny.so

account     required      pam_unix.so broken_shadow
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     [default=bad success=ok user_unknown=ignore] pam_ldap.so
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3
password    sufficient    pam_unix.so md5 shadow nullok try_first_pass 
use_authtok
password    sufficient    pam_ldap.so use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in 
crond quiet use_uid
session     required      pam_unix.so
session     required      pam_mkhomedir.so skel=/etc/skel/ umask=0077
session     optional      pam_ldap.so

Также есть конфигурация для tacacs, которая выглядит очень простой, но, как и все остальное, я никогда ее раньше не видел, поэтому я ' м не слишком уверен. Выглядит это так: services: cis-api: image: docker.myserver.com/cis-api:latest ...

У меня есть среда Ubuntu 16.04 с Docker в Digital Ocean, и я загружаю службу с помощью docker-compose:

version: '2'
services:
  cis-api:
    image: docker.myserver.com/cis-api:latest
    ports:
      - 8080:5000
    environment:
      DB_CONN_STRING: 'Server=tcp:...;Initial Catalog=cis-stage;Persist Security Info=False;User ID=...;Password=...;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;'

Затем у меня установлен ванильный Nginx с одной конфигурацией внутри /etc/nginx/conf.d :

upstream cis-api {
  server 0.0.0.0:8080;
}

server {
  listen 80;
  server_name cis-api.myserver.com;

  location / {
    proxy_pass                          http://cis-api;
    proxy_set_header  Host              $http_host;   # required for docker client's sake
    proxy_set_header  X-Real-IP         $remote_addr; # pass on real client's IP
    proxy_set_header  X-Forwarded-For   $proxy_add_x_forwarded_for;
    proxy_set_header  X-Forwarded-Proto $scheme;
    proxy_read_timeout                  900;
  }
}

Когда я пытаюсь запросить URL-адрес в обход nginx, все работает:

root@cis-stage:/etc/nginx# curl localhost:8080/businesses -H 'Authorization: Bearer ...'
[{"id":1,...,"email":null}]

Однако, если я попытаюсь выполните тот же самый запрос, проходящий через nginx, соединение зависнет, или если я установил тайм-аут 30 секунд, он истечет:

root@cis-stage:/etc/nginx# curl --max-time 30 --connect-timeout 30 http://cis-api.mysever.com/businesses -H 'Authorization: Bearer ....'

curl: (28) Operation timed out after 30000 milliseconds with 0 bytes received

Приложение написано на ASP.Net Core 1.1, и вот разница в выходе, когда я запускаю его в обход nginx:

cis-api_1  | dbug: Microsoft.AspNetCore.Server.Kestrel[1]
cis-api_1  |       Connection id "0HL3OL7D1CF19" started.
cis-api_1  | info: Microsoft.AspNetCore.Hosting.Internal.WebHost[1]
cis-api_1  |       Request starting HTTP/1.1 GET http://localhost:8080/businesses
cis-api_1  | info: Microsoft.AspNetCore.Authentication.JwtBearer.JwtBearerMiddleware[2]
cis-api_1  |       Successfully validated the token.
cis-api_1  | info: Microsoft.AspNetCore.Authentication.JwtBearer.JwtBearerMiddleware[3]
cis-api_1  |       HttpContext.User merged via AutomaticAuthentication from authenticationScheme: Bearer.
cis-api_1  | info: Microsoft.AspNetCore.Hosting.Internal.WebHost[2]
cis-api_1  |       Request finished in 414.6261ms 200 application/json; charset=utf-8
cis-api_1  | dbug: Microsoft.AspNetCore.Server.Kestrel[6]
cis-api_1  |       Connection id "0HL3OL7D1CF19" received FIN.
cis-api_1  | dbug: Microsoft.AspNetCore.Server.Kestrel[9]
cis-api_1  |       Connection id "0HL3OL7D1CF19" completed keep alive response.
cis-api_1  | dbug: Microsoft.AspNetCore.Server.Kestrel[10]
cis-api_1  |       Connection id "0HL3OL7D1CF19" disconnecting.
cis-api_1  | dbug: Microsoft.AspNetCore.Server.Kestrel[7]
cis-api_1  |       Connection id "0HL3OL7D1CF19" sending FIN.
cis-api_1  | dbug: Microsoft.AspNetCore.Server.Kestrel[8]
cis-api_1  |       Connection id "0HL3OL7D1CF19" sent FIN with status "0".
cis-api_1  | dbug: Microsoft.AspNetCore.Server.Kestrel[2]
cis-api_1  |       Connection id "0HL3OL7D1CF19" stopped.

По сравнению с тем, когда я запускаю nginx в качестве прокси:

cis-api_1  | dbug: Microsoft.AspNetCore.Server.Kestrel[1]
cis-api_1  |       Connection id "0HL3OL7D1CF1B" started.
cis-api_1  | info: Microsoft.AspNetCore.Hosting.Internal.WebHost[1]
cis-api_1  |       Request starting HTTP/1.0 GET http://cis-api.myserver.com/businesses
cis-api_1  | info: Microsoft.AspNetCore.Authentication.JwtBearer.JwtBearerMiddleware[2]
cis-api_1  |       Successfully validated the token.
cis-api_1  | info: Microsoft.AspNetCore.Authentication.JwtBearer.JwtBearerMiddleware[3]
cis-api_1  |       HttpContext.User merged via AutomaticAuthentication from authenticationScheme: Bearer.

Он зависает здесь, пока не истечет время ожидания запроса, а затем:

cis-api_1  | dbug: Microsoft.AspNetCore.Server.Kestrel[6]
cis-api_1  |       Connection id "0HL3OLAD6F4QN" received FIN.
cis-api_1  | info: Microsoft.AspNetCore.Hosting.Internal.WebHost[2]
cis-api_1  |       Request finished in 4615.4522ms 200 application/json; charset=utf-8
cis-api_1  | dbug: Microsoft.AspNetCore.Server.Kestrel[10]
cis-api_1  |       Connection id "0HL3OLAD6F4QN" disconnecting.
cis-api_1  | dbug: Microsoft.AspNetCore.Server.Kestrel[7]
cis-api_1  |       Connection id "0HL3OLAD6F4QN" sending FIN.
cis-api_1  | dbug: Microsoft.AspNetCore.Server.Kestrel[8]
cis-api_1  |       Connection id "0HL3OLAD6F4QN" sent FIN with status "-107".
cis-api_1  | dbug: Microsoft.AspNetCore.Server.Kestrel[2]
cis-api_1  |       Connection id "0HL3OLAD6F4QN" stopped.

Есть идеи?

0
задан 1 April 2017 в 05:57
1 ответ

После долгих исследований я нашел здесь ответ:

https://github.com/aspnet/KestrelHttpServer/ issues / 468 # issuecomment-165951249

И проблема была решена путем изменения файл конфигурации nginx для добавления нового заголовка прокси:

proxy_set_header  Connection        keep-alive;

Новый блок location стал:

  location / {
    proxy_pass                          http://cis-api;
    proxy_set_header  Host              $http_host;   # required for docker client's sake
    proxy_set_header  X-Real-IP         $remote_addr; # pass on real client's IP
    proxy_set_header  X-Forwarded-For   $proxy_add_x_forwarded_for;
    proxy_set_header  X-Forwarded-Proto $scheme;
    proxy_set_header  Connection        keep-alive;
    proxy_read_timeout                  900;
  }

Теперь все работает, как ожидалось

1
ответ дан 4 December 2019 в 16:18

Теги

Похожие вопросы