If I am authenticating using PAM, is it a standard/best practice to use pam_unix in syslog tags? Who added pam_unix in below log: vsftpd process or the PAM module itself which was used in authentication?
For example-
Feb 25 13;01:14 hostname vsftpd(pam_unix)[10561]: authentication failure : logname= uid== euuid=0 tty= ruser= rhost=a.b.c.d user=ron
The pam_unix module logs this. See modules/pam_unix/support.c in the pam library sources.
Related
I'm trying to restrict an url called by Docusign event when a document is completed.
I want to only give access to this url by Docusign host or ip but i'm unable to do so because of my limited skills on Apache.
By following this documentation https://www.docusign.com/trust/security/esignature
I've tried to add this line in my vhost :
<LocationMatch "^/souscription/api/[^/].*/callback/.*$">
Require host docusign.com docusign.net
</LocationMatch>
But I have this error in apache log:
[Wed Jul 29 12:59:09.663648 2020] [authz_host:error] [pid 32671] [client 162.248.186.11:50836] AH01753: access check of 'docusign.com docusign.net' to /souscription/api/1.0/callback/118/completed failed, reason: unable to get the remote host name
What's wrong with my config ?
For Apache questions, use superuser.com
When building a listening server for receiving DocuSign webhook messages, filtering by IP is not recommended since it leads to a brittle installation that can fail at exactly the wrong time. Instead:
Use the combination of the Basic Authentication and HMAC features to assure yourself that the message really came from DocuSign.
Or better, use an intermediate PaaS service to queue the notification messages. The additional feature is that you can receive the notification messages from behind your firewall with no changes to the firewall. See the example repo and associated blog posts.
I am trying to use mod_authz_ldap for user authentication. Have a strange LDAP setup where, we have to bind to the LDAP directory as
uid=user,o=organisation
then query
cn=xxx,o=organisation
to get the credentials of the user. The following configuration actually works, except that it attempts to use the credentials of the user logging in to bind to the LDAP directory, which needless to say fails.
To validate this, I tried to authenticate to the application as our LDAP bind user and the authentication succeeds.
<Location />
AuthType Basic
AuthName "My LDAP authenticated app"
AuthzLDAPLogLevel debug
AuthBasicProvider ldap
AuthBasicAuthoritative off
AuthzLDAPAuthoritative off
AuthzLDAPBindPassword bindpass
AuthzLDAPBindDN "uid=binduser,o=my.edu.au"
AuthzLDAPMethod ldap
AuthzLDAPServer ldapdevel.my.edu.au
AuthzLDAPUserBase o=my.edu.au
AuthzLDAPUserKey cn
AuthzLDAPUserScope base
AuthLDAPRemoteUserAttribute cn
Require valid-user
</Location>
Apache error log to demonstrate that mod_authz_ldap is attempting to bind as the user attempt to authenticate agains the app:
[Fri Sep 07 14:14:27 2012] [error] [client xxx.xxx.xxx.xxx] [15628] bind as cn=devraj,l=X,ou=Students,o=my.edu.au failed: 49
[Fri Sep 07 14:14:27 2012] [error] [client xxx.xxx.xxx.xxx] [15628] basic LDAP authentication of user 'devraj' failed
[Fri Sep 07 14:14:27 2012] [error] [client xxx.xxx.xxx.xxx] access to / failed, reason: verification of user id 'devraj' not configured
Also if I provide incorrect bind credentials mod_authz_ldap complains about not being able to bind as the bind user. This suggests that it tries to bind as the bind user, but also binds as the authenticating user.
My Question, what am I doing wrong that's causing mod_auz_ldap to use the users credentials to bind to the LDAP directory?
Thanks for your time.
Why is AuthzLDAPBindDN "uid=binduser,o=my.edu.au"?
Then you show AuthzLDAPUserKey cn.
The "uid=binduser,o=my.edu.au" should typically, be a valid user from LDAP and usually a service account.
Then the AuthzLDAPUserKey cn would represent the RDN (Relative Distinguished Name) attribute of users in LDAP. It would be non-typical for you to have a user uid=binduser and other users to be like: cn=devraj.
Does uid=binduser,o=my.edu.au exist?
Does the user cn=devraj,l=X,ou=Students,o=my.edu.au exist?
(or is it: uid=devraj,l=X,ou=Students,o=my.edu.au)
-jim
it attempts to use the credentials of the user logging in to bind to the LDAP directory, which needless to say fails
Why 'needless to say'? And why does it fail at all? This is exactly what it is supposed to do. Normally you should be searching the directory for the user, possibly using a system account to do so, then binding as the found user with his credentials. If that succeeds, authentication is complete. If your LDAP isn't set up to support that, it is set up wrongly.
Problems appear when accessing Kerberos protected site by IP address.
For example:
http:/10.10.1.x:3001/ gives failure.
http:/my-host:3001/ sso is completes successfully.
Apache error logs say:
src/mod_auth_kerb.c(1261): [client 10.10.1.x] Acquiring creds for
HTTP#10.10.1.x [client 10.10.1.x] gss_acquire_cred() failed:
Unspecified GSS failure. Minor code may provide more information (Key
table entry not found)
src/mod_auth_kerb.c(1261): [client 10.10.1.x Acquiring creds for
HTTP#my-host [debug] src/mod_auth_kerb.c(1407): [client 10.10.1.x]
Verifying client data using KRB5 GSS-API [debug]
src/mod_auth_kerb.c(1423): [client 10.10.1.x] Verification returned
code 0
As you could see Kerberos tries to find HTTP#10.10.1.x or HTTP#my-host principals. For both principals created dummy accounts in ActiveDirectory. In keytab file also included both of them:
KVNO Timestamp Principal
---- ----------------- -----------------------------------------------------
5 01/01/70 03:00:00 HTTP/10.10.1.x#MY_DOMAIN.LAN (ArcFour with HMAC/md5)
11 09/04/12 12:03:01 HTTP/my-host#MY_DOMAIN.LAN (ArcFour with HMAC/md5)
Kinit works for both of them.
Kerberos config on server:
Krb5Keytab /etc/krb5.keytab
AuthType Kerberos
KrbMethodNegotiate On
AuthName "Kerberos Login"
KrbAuthRealms MY_DOMAIN.LAN
KrbVerifyKDC Off
KrbMethodK5Passwd On
Require valid-user
Someone could guess where the problem is? Is it possible to use IP address in Kerberos SSO?
Kerberos does not work with IP adresses, it relies on domain names and correct DNS entries only.
In a Microsoft KB article it says that is by design:
https://support.microsoft.com/en-ca/kb/322979
The title of the above KB is:
Kerberos is not used when you connect to SMB shares by using IP address
I realize this is a very old thread, but it is a top choice for any related searches. I think it's worth noting that Microsoft has recently added Kerberos client support using IPv4 and IPv6.
Beginning with Windows 10 version 1507 and Windows Server 2016,
Kerberos clients can be configured to support IPv4 and IPv6 hostnames
in SPNs.
To reduce the impact of disabling NTLM a new capability was introduced
that lets administrators use IP addresses as hostnames in Service
Principal Names. This capability is enabled on the client through a
registry key value.
Since this is a client-side fix, your Kerberos client must be running an appropriate version of Windows and receive the TryIPSPN registry entry. Your service must also have an IP-based SPN registered to it in Active Directory.
I recently changed my root password, but when I restart Ldap (openldap-2.2.13) I couldn't log in with Ldap users to any application that is on this server.
in /var/log/httpd/ssl_error_log I can find a lot of error like:
[Tue Jun 01 02:27:24 2010] [warn] [client 89.138.98.214] [26762] auth_ldap authenticate: user foo authentication failed; URI /svn-clients/clients/myclient/ [LDAP: ldap_simple_bind_s() failed][Can't contact LDAP server]
I guess there is a linkage between user root and the Ldap configuration, I also changed the
rootpw entry in slapd.conf, but this doesn't seem to make things better.
The server is not running. I would restart on the commandline and immediately check for error messages in /var/log/daemon.log
I have been trying to follow the guidelines in this Microsoft article to authenticate
against Apache with Kerberos and AD. I have successfully tested the communication between the apache server and the AD server with kinit. However when I attempt to access a restricted page on the server with IE I get an Internal server error and the following appears in the apache error log.
[Wed Sep 24 14:18:15 2008] [debug] src/mod_auth_kerb.c(1483): [client 172.31.37.38] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
[Wed Sep 24 14:18:15 2008] [debug] src/mod_auth_kerb.c(1174): [client 172.31.37.38] Acquiring creds for HTTP/srvnfssol1.dev.local#DEV.LOCAL
[Wed Sep 24 14:18:15 2008] [error] [client 172.31.37.38] gss_acquire_cred() failed: Miscellaneous failure (see text) (Key table entry not found)
I have run a truss on the apache process and confirmed that it is in fact loading up the keytab file ok. I am wondering if there is something wrong with the format of the keytab file...
HTTP/srvnfssol1.dev.local#DEV.LOCAL
I am not sure what I am missing though. Or what other things to check.
Any suggestions?
Thanks
Peter
Ok. Keytabs are supposed to contain the Service principal name, in this case "HTTP/srvnfssol1.dev.local#DEV.LOCAL" and the encryption key. I see where the MS docs say just to echo that to a file, but I don't think that's right.
You'll need to use the ktpass utility to create the keytab. The MS docs are here.
In particular, you'll need to specify KRB5_NT_SRV_HST, and most of the rest of the options can be default.
Sample of it on my machine:
C:\>ktpass /out test.keytab /princ HTTP/srvnfssol1.dev.local#DEV.LOCAL
/ptype KRB5_NT_SRV_HST /pass *
Type the password for HTTP/srvnfssol1.dev.local:
Key created.
Output keytab to test.keytab:
Keytab version: 0x502
keysize 62 HTTP/srvnfssol1.dev.local#DEV.LOCAL
ptype 3 (KRB5_NT_SRV_HST) vno 1 etype 0x1 (DES-CBC-CRC)
keylength 8 (0xa7f1fb38041c199e)
If the active directory server is the KDC, you'll need to use the /map <name> argument, where <name> is the computer account in active directory representing the server.
Some details on how all this works. When you browse to the website it should respond with a WWW-Authenticate: Negotiate header, and your browser will send a request to the KDC (active directory server) to get a kerberos ticket for the service. The AD server will look up the encryption key for the ticket using the service principal name, and send an encrypted service ticket back to the browser. Once the browser has the service ticket, it'll reissue the HTTP request with an authenticate header containing the ticket. The apache server will look up its key in the keytab, decrypt the ticket, and grant access.
The "key table entry not found" error happens because apache isn't finding itself in the keytab. Can also happen if the name resolution/realms aren't set up right.
You should be able to see all the kerberos requests AP-REQ/AP-REP/TGS-REQ/TGS-REP using wireshark on the client, tcp or udp port 88.