Closed mlcpap closed 2 years ago
I added the following to my .env AUTH_LDAP_USER_SEARCH_FILTER=(sAMAccountName=%(user)s)
and I edited /etc/systemd/system/alcali.service to enable logging to syslog: ExecStart=/opt/alcali/.venv/bin/gunicorn --log-syslog config.wsgi:application --bind 0.0.0.0:5000 -w 4 -t 300
And now I see the following in /var/log/messages when I attempt to login as my AD user: Feb 25 08:17:56 saltmaster alcali[116437]: search_s('OU=IT,DC=dom,DC=pri', 2, '(sAMAccountName=%(user)s)') returned 1 objects: cn=first.last,ou=it,dc=dom,dc=pri Feb 25 08:17:56 saltmaster alcali[116437]: Populating Django user first.last
I ran alcali dbshell and manually updated the db so that my user is_staff=1.
However, I still get the "Invalid Login / Password" message. This might be because of a logging error. Not sure if this was introduced by the fact that I am logging at all now and it also wants access log and error log defined for the django instance. This is not logged every time, and perhaps only after the 3rd or 4th time I try to login:
Feb 25 08:21:22 saltmaster alcali[116437]: --- Logging error ---
Feb 25 08:21:22 saltmaster alcali[116437]: Traceback (most recent call last):
Feb 25 08:21:22 saltmaster alcali[116437]: File "/usr/lib64/python3.6/logging/handlers.py", line 942, in emit
Feb 25 08:21:22 saltmaster alcali[116437]: self.socket.sendto(msg, self.address)
Feb 25 08:21:22 saltmaster alcali[116437]: OSError: [Errno 9] Bad file descriptor
Feb 25 08:21:22 saltmaster alcali[116437]: Call stack:
Feb 25 08:21:22 saltmaster alcali[116437]: File "/opt/alcali/.venv/bin/gunicorn", line 8, in
Seems to die right after POST /api/token and the successful ldap check.
Digging much deeper, it seems that login calls validate() in MyTokenObtainPairSerializer from api/serializers. This reaches into /opt/alcali/.venv/lib/python3.6/site-packages/rest_framework_simplejwt/serializers.py to perform auth against the backend. With debug added, I pass all of the steps here. This serializers.py calls out to authenticate() in /opt/alcali/.venv/lib/python3.6/site-packages/django/contrib/auth/init.py
I can get debug out of all of the above, but the original validate function exits:
class MyTokenObtainPairSerializer(TokenObtainPairSerializer):
def validate(self, attrs):
# /opt/alcali/.venv/lib/python3.6/site-packages/django/contrib/auth/__init__.py
# /opt/alcali/.venv/lib/python3.6/site-packages/rest_framework_simplejwt/serializers.py
print("Calling validate for:")
print(attrs)
data = super().validate(attrs) <---- correctly calls code in rest_framework and django.contrib.auth, which can be made to print debug output showing that the login is successful
print("Validated user " + self.user.username) <--------------not printed
print(type(data)) <--------------- not printed
refresh = self.get_token(self.user)
data["refresh"] = str(refresh)
Since my AD user is first.last, could it be dieing because of the '.' ? EDIT: No, that isn't it.
Turns out I am running into this instead upon successful login: File "/opt/alcali/.venv/lib/python3.6/site-packages/rest_framework_simplejwt/backends.py", line 43, in encode return token.decode('utf-8') AttributeError: 'str' object has no attribute 'decode' If I change that function to return token instead of token.decode, I get logged in. Of course I cannot auth to salt at that point but there is some progress...
Pretty well non-standard since it is a mod of the django code, but "/opt/alcali/.venv/lib/python3.6/site-packages/rest_framework_simplejwt/backends.py":
if (type(token) == str):
return token
return token.decode('utf-8')
This lets me login and get around in Alcali without error. However, about the only thing I can see are events, which stands to reason since mysql is working. But, no errors when I run gunicorn in foreground with debug but no content from salt.
Describe the bug I am unable to login as the admin after installing alcali as a salt formula onto a new salt-master running 3004.1.
To Reproduce Attempt to login via web browser and get invalid login error in red.
Expected behavior Successful login
Desktop (please complete the following information):
Additional context Server OS is the latest release of Almalinux as of this date. I found no alcali command but created a shell script containing this as a shortcut: ENV_PATH=/opt/alcali /opt/alcali/.venv/bin/python3 /opt/alcali/code/manage.py "$@"
alcali check works, as does changepassword, createsuperuser, etc. And the db has the extra tables created by alcali in addition to the default ones needed for salt. Salt is also actively populating that db.
I have tried with and without LDAP, but my current obfuscated .env shows: AUTH_BACKEND="ldap" DB_BACKEND="mysql" DB_NAME="salt" DB_USER="alcali" DB_PASS="dbpassword" DB_HOST="localhost" DB_PORT="3306" MASTER_MINION_ID="saltmaster.dom.pri" SECRET_KEY="thisisnotagoodsecret.orisit?" ALLOWED_HOSTS="" SALT_URL="https://saltmaster.dom.pri:8080" SALT_AUTH="alcali" AUTH_LDAP_SERVER_URI="ldaps://ad.dom.ctrl.dom.pri" AUTH_LDAP_USER_BASE_CN="dc=dom,dc=pri" AUTH_LDAP_USER_SEARCH_FILTER="(objectClass=)" AUTH_LDAP_BIND_DN="FullDN of LDAP query user" AUTH_LDAP_BIND_PASSWORD="binddn_password"
Removing AUTH_BACKEND or setting to "None" has the same effect. Also, fwiw, my salt formula is being picked up and applied but the /srv/pillar/alcali.sls file appears to not get used at all. In there I am attempting to install the latest version 3003.2. I have had to adjust some of the pkg installs since we are also using Percona instead of mysqld or mariadb. But the db does appear to be working otherwise.