I'm currently trying to implement GSSAPI support in a third-party LDAP library (the Common Lisp library trivial-ldap). I got it to work when authenticating to an AD server (using the mechanism GSS-SPNEGO) but when trying to talk to an OpenLDAP server I get an error reply from the server saying that the mechanism is not supported.
It turns out that OpenLDSP doesn't support GSS-SPNEGO, but instead wants GSSAPI. The protocol used to do GSSAPI authentication seems very different from GSS-SPNEGO, but my problem is that I can't figure out is what way.
Is there anyone that could assist in explaining how the GSS packets are supposed to be wrapped inside the SASL messages when using the mechanism GSSAPI?
I tried simply sending packets in the same form as GSS-SPNEGO, but when I do so the SASL handshake never ends. After the context has been created, I keep getting result code 14 (LDAP_SASL_BIND_IN_PROGRESS) as a response to anything I send.
You can safely use the GSSAPI SASL mech. This is plain Kerberos 5. GSS-SPNEGO is just SPNEGO which will try Kerberos 5 first and if this fails it may resort to NTLM. Active Direcory supports DIGEST-MD5, and the two mentioned mechs. I've been using GSSAPI mech for years from Windows and Unix.
Related
I have a web application which is developed using vb.net.
My web application uses Windows authentication mode.
Security team scanned the application and reported one issue.
Steps followed to produce the issue:
1. Type the url in browser (url - https://sample/applicationname) and press Enter
2. Analyze the response using proxy tool 'Fiddler' - which shows that authentication method in NTLM which is insecure.
Recomendations given by security team:
Change authentication method to a more secure one such as Digest, client certificates or similar. Otherwise use an encrypted channel to protect information by implementing HTTPS.
Note: HTTPS is already implemented.
Kindly let me know how to solve the issue.
Thanks in advance.
Digest is less secure than NTLM, so you may want to mock your security team. Digest uses MD5 (in a weak manner) and requires reversible passwords. If you really want to go more secure than NTLM, your may want to configure kerberos. The options vary depending on your version of IIS. Google will have your answer.
It is possible to make kerberos module for Apache server who is on windows? I understand that i need to make dll file from some source, but how?
Thank you.
Try http://modauthkerb.sourceforge.net/
Mod_auth_kerb is an Apache module designed to provide Kerberos authentication to the Apache web server. Using the Basic Auth mechanism, it retrieves a username/password pair from the browser and checks them against a Kerberos server as set up by your particular organization. The module also supports the Negotiate authentication method, which performs full Kerberos authentication based on ticket exchanges, and does not require users to insert their passwords to the browser. In order to use the Negotiate method you need a browser supporting it (currently standard IE6.0 or Mozilla with the negotiateauth extension).
This is probably a dumb question but can I do away safely with just basic HTTP auth or do I still benefit from digest auth even if the server is already on SSL?
The only advantage you would gain by using HTTP Digest authentication over SSL/TLS is to prevent the disclosure of the user password to the server itself, if your sever is capable of being configured with passwords in "HA1 format" directly (i.e. if it doesn't need to know the password itself, but where the user password can be configured with MD5(username:realm:password), without requiring the password in clear, see Apache Httpd for example).
In practice, this isn't really a big advantage. There are better alternatives if protecting the password itself from the server is required (in particular because MD5 isn't considered good enough anyway nowadays).
The other features of HTTP Digest authentication (over form/HTTP Basic) are already provided by the SSL/TLS layer.
Across ssl basic auth is secure enough for most needs.
I've been searching for a bit now, but I can't find an answer. WCF Security Best Practices say to use Windows Authentication when possible. Can this provide non-repudiation and data integrity if you require signing?
(The most important question here is non-repudiation. I'm using TLS but trying to determine if I can provide non-repudiation through Windows Auth with TLS or MLS. Theoretically, the TLS provides hop-to-hop data integrity.)
Yes, for first question. Check this:
Chapter 4: WCF Security Fundamentals
Windows Authentication does not provide data signing.
Windows Authentication is preferrable and suggested by the best practice guide because it is built in all Microsoft machines. It doesn't like the certificate that requires a lot of infrastructure setup. If your machine is joined to an Active Directory domain, it should just work.
Windows Authentication is using SPNEGO to negotiate to use which authentication method, Kerberos or NTLM. Whenever possible, client and server will try to pick Kerberos first. Otherwise, NTLM will be used.
To answer your question of whether the message can be sigend or not, both Kerberos and NTLM can be used to sign and encrypt messages. As a WCF programmer, it should be transparent to you. All you need to do is to set the ProtectedLevel to EncryptAndSign. If you don't believe me, you can look at the network trace after setting up the Windows Authentication. You should see the messages are encrypted.
When using the Windows Authentication, WCF will call SSPI to do authentication and message encryption. I won't cover the detials of SSPI. Here is the SSPI call for NTLM to encrypt message and here is the SSPI call for Kerberos to encrypt message. You can set a break point in Windbg to prove that.
Although it's not explicitly stated in the above links, this link clearly states that the above mentioned EncryptMessages methods can provide data integrity (signing) and privacy (encryption).
Back to your original question about whether Windows authentication support non-repudiation, this is actually a bigger question. Data signing is necessary for non-repudiation but not sufficient. WCF is also providing the auditing feature to record operation or transaction. This is to guarantee that a user cannot deny performing an operation or initiating a transaction. So, in order to support non-repudiation, you should also set SuppressAuditFailure to false to make sure auditing is always functioning properly.
I am doing a project which involves authentication and I can't quite grasp the difference between SASL and gssapi. Is gssapi used under the covers of SASL? Can I use gssapi without SASL? What is the correct thing to do?
If I use libsasl, do I need to link with libgssapi_*?
Thanks.
SASL and gssapi basically solve the same problem in different ways. Both are a way to find the best common authentication method to use between two systems.
So no, gssapi isn't used under the hood in SASL, unless you use something like RFC4752
Yes, you can use gssapi without SASL, examples of that would be the typical linux machine logging into a windows AD domain via the kerberos/gssapi providers.
It all depends on what kind of authentication scenarios you have to implement, both SASL and gssapi have their uses. GSSAPI is most commonly used with the Kerberos system.