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.
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've changed my sip providers ip to MY.SIP.PROV.IP and their domain to MYSIPPROVIDER.COM and also my phone number to XXXXXXXXXX....
This is the CLI log. I'm able to dial out but I cannot get inbound routes working... Any help is appreciated.
Main part I'm not understanding:
2016-03-09 22:59:50.981898 [DEBUG] sofia.c:9124 IP MY.SIP.PROV.IP Rejected by acl "domains". Falling back to Digest auth.
Second Part....
2016-03-09 22:59:50.981898 [WARNING] sofia_reg.c:2852 Can't find user [#MYSIPPROVIDER.COM] from MY.SIP.PROV.IP
You must define a domain called 'MYSIPPROVIDER.COM' in your directory and add a user with the id="" attribute
and you must configure your device to use the proper domain in it's authentication credentials.
2016-03-09 22:59:50.981898 [WARNING] sofia_reg.c:1703 SIP auth failure (INVITE) on sofia profile 'internal' for [XXXXXXXXXX#MYSIPPROVIDER.COM] from ip MY.SIP.PROV.IP
If you look at the vars.xml file (located in /etc/freeswitch/vars.xml if you installed from the FreeSWITCH package) you'll see two relevant settings..
<X-PRE-PROCESS cmd="set" data="internal_sip_port=5060"/>
<X-PRE-PROCESS cmd="set" data="external_sip_port=5080"/>
In short, if a SIP packet is sent to your FreeSWITCH box on port 5080, it get's routed to the /etc/freeswitch/dialplan/public.xml file. Which, if you installed from package, also includes any .xml in /etc/freeswitch/dialplan/public/ using the line..
<X-PRE-PROCESS cmd="include" data="public/*.xml"/>
Otherwise, if you receive a packet on port 5060 of your FreeSWITCH box it gets treated as an 'internal' call. These get treated a little differently. If you're using default/example configuration, one of the differences is the FreeSWITCH ACL or 'Access Control List'.
Basically, any call made to 5060 will be parsed by the ACL. Which you can perceive as a sort of firewall. If it doesn't match a rule in there, FreeSWITCH refuses it with the error.
2016-03-09 22:59:50.981898 [DEBUG] sofia.c:9124 IP MY.SIP.PROV.IP Rejected by acl "domains". Falling back to Digest auth.
And this part...
2016-03-09 22:59:50.981898 [WARNING] sofia_reg.c:2852 Can't find user [#MYSIPPROVIDER.COM] from MY.SIP.PROV.IP
You must define a domain called 'MYSIPPROVIDER.COM' in your directory and add a user with the id="" attribute
and you must configure your device to use the proper domain in it's authentication credentials.
...is being generated by this part of the ACL config...
<list name="domains" default="deny">
<node type="allow" domain="$${domain}"/>
</list>
...Take not of the "Allow any SIP packet where the 'domain' (eg the #mysipprovider.com part of the SIP URI) is part of a user defined in the 'FreeSWITCH Directory'.
In short, the ACL is used as an added measure of authenticating INTERNAL DEVICES, in the context where FreeSWITCH is used as an 'internal PBX'.
You have two options..
Ask mysipprovider to route inbound SIP packets to port 5080, and then look at managing inbound calls via the default /etc/freeswitch/dialplan/public/00_inbound_did.xml file
Add a specific line in the ACL to approve calls from mysipprovider. Maybe something like..
..then type..
fs_cli -x 'reloadacl'
..to apply it.
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.
I have implemented SSO through mod_auth_kerb in our apache-active directory environment and it works just as expected. However the following knowledge is bugging me :
I requested a Kerberos protected page from two client machines, one user belonged to the Kerberos-setup domain and the other user belonged to some other domain.
I then compared the HTTP packets on the two machines. On both the machines, after the request for the Kerberos protected page is sent, the server responds with the following HTTP packet :
HTTP/1.1 401 Authorization Required
Date: Wed, 05 Sep 2012 14:25:20 GMT
Server: Apache WWW-Authenticate: Negotiate
WWW-Authenticate: Basic realm="Kerberos Login"
Content-Length: 60
Connection: close
Content-Type: text/html; charset=iso-8859-1
However, after the above response from the server the client machine's browser belonging to the Kerberos-setup domain responds with a WWW-Authenticate : Negotiate 'token', whereas the other client browser(user belonging to some other domain) does not respond at all.
Now my understanding is, that the client belonging to the other domain should have also responded with its own TGT+Session key token, which the active directory should have rejected. But why this client does not respond at all to the server's WWW-Authenticate : Negotiate challenge is beyond my logic.
What is even more confusing is that the server's HTTP response(given above), does not contain any information about the domain it is linked to.
So on what basis is the client browser belonging to the correct domain decide that it has to respond to the server's WWW-Authenticate : Negotiate challenge, and on what basis does the client belonging to some other domain decide not to respond to the same ?
Note : Both the client machines have Windows 7 and active directory is a Windows 2008 server.
I am trying to understand mod_auth_kerb's implementation of SSO, and this particular knowledge is key to that.
The module has the option KrbMethodK5Passwd turned on. It sends a Basic header to collect you Kerberos credentials. This is pointless for a non-domain client. Disable this option.
There is a hierarchy of strengths of auth mechanisms, the browser is obliged to choose the best. This is: Negotiate, Digest, NTLM, Basic.
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.