I am trying to connect a server to a XMPP server, using the MD5 Digest SASL handshake. But the XMPP server always rejects my response to the challenge. The RFC says the response should look like:
username="example.org",realm="somerealm",\
nonce="OA6MG9tEQGm2hh",cnonce="OA6MHXh6VqTrRk",\
nc=00000001,qop=auth,digest-uri="xmpp/example.org",\
response=d388dad90d4bbd760a152321f2143af7,charset=utf-8
But the value of response (which I have correctly generated based on the inputs) relies on the username and password. For server-to-server communication, which username and password should it be using? The example.org username in the spec doesnt seem right..
You've probably solved this by now, but this is for the record. See RFC3920, section 6.1, item 6: "If provision of a 'simple username' is supported by the selected SASL mechanism (e.g., this is supported by the DIGEST-MD5 and CRAM-MD5 mechanisms but not by the EXTERNAL and GSSAPI mechanisms), during authentication the initiating entity SHOULD provide as the simple username its sending domain (IP address or fully qualified domain name as contained in a domain identifier) in the case of server-to-server communications or its registered account name (user or node name as contained in an XMPP node identifier) in the case of client-to-server communications."
At least, that conditionally takes care of the username. The password I couldn't even guess at. I'm writing a client-to-server script, so I'll be using my own gmail username and password, but that isn't likely to work for server-to-server.
Related
I have configured Active Directory Federation Service (ADFS) and Web Application Proxy (WAP) with a Non-Claims Aware Relying Party Trust so that I can serve an IIS Web Application to users connecting from the extranet. Keycloak is configured as an external identity provider to perform X.509 authentication of users using a smart card and returning a SAML 2.0 assertion to ADFS. The authorization flow in Keycloak returns the Subject Alternative Name (Other - UPN) as the nameid. A claims rule is set up in ADFS to transform the incoming Name ID value to a UPN, and the domain name of the UPN is replaced with the internal domain name of the intranet.
The final piece of this authentication/authorization scheme is to edit the Active Directory users' UPN to match the incoming UPN, so a kerberos ticket can be granted for the incoming web request.
This all works! Here is the problem:
For users who have not had the final step performed, mapping the X.509 SAN UPN to their Active Directory UPN, the web request returns an HTTP 500 error, and the event log on the WAP records these errors:
Web Application Proxy cannot retrieve a Kerberos ticket on behalf of the user because of the following general API error: The user name or password is incorrect. (0x8007052e).
Web Application Proxy encountered an unexpected error while processing the request. Error: The user name or password is incorrect. (0x8007052e)
Is there any way to customize the error being returned to such a user, to let them know they need to contact their system administrator to have their account configuration updated?
The only powershell error-customization cmdlets I've found don't seem to affect this particular error situation, and it's not particularly helpful to the end user to get a "This page isn't working right now" message.
We have a client/server based application that is developed internally. Clients and server communicate over a TCP/IP connection with an application-specific protocol. The clients run on Windows and the server runs on Linux. All machines are in the same Active Directory/Kerberos domain/realm.
Currently, the user enters a username and password when they start the application. The server checks the username and password (authentication). Based on the username, the server also determines access to resources (authorization).
We want to add Single Sign-On (SSO) capabilities to the application. That is, we do not want the user to enter a username and password but we want to automatically logon as the current Windows user.
Of course, determining the current Windows user has to be done securely.
I have come up with the following setup:
I use SSPI (Negotiate) on Windows and GSSAPI on Linux.
When the client connects to the server, it uses AcquireCredentialsHandle (Negotiate) to get the credentials of the current Windows user.
The client uses InitializeSecurityContext (Negotiate) to generate a token based on these credentials.
The client sends the token to the server.
The server uses gss_acquire_cred() to get the credentials of the service. These are stored in a .keytab file.
The server receives the token from the client.
The server uses gss_accept_sec_context() to process the token. This call also returns the "source name", that is the current Windows user of the client.
The server uses the "source name" as the username: the server performs no additional authentication. The server still performs authorization.
This works but I do have some questions:
Is this secure? It should not be possible for the client to specify any other username than the Windows user of the client process. If a user has the credentials to create a process as another user (either legally or illegally) than this is allowed.
Should I perform additional checks to verify the username?
Are there alternative ways to achieve SSO in this setup? What are their pros and cons?
What you've described here is the correct way to authenticate the user. You should not have to worry about the user specifying a different name; that's what Kerberos takes care of for you.
If the client is able to obtain a service ticket, then they must have been able to authenticate against the KDC (Active Directory). The KDC creates a service ticket that includes the user's name, and encrypts it with the service's secret key.
The client would not be able to create a ticket for the server with a fake name, because it doesn't have the necessary key to encrypt the ticket.
Of course, this all assumes that you've set everything up correctly; the client should not have access to the service's keytab file for example, and the service should not have any principals in its key tab except its own.
There's a pretty detailed explanation of how it works here.
I need to setup a cron job to run a SOAP client. The customer insists that I connect to their web service (on an https address) from an https address. They insist that if I don't their response to me can't be encrypted.
My first question is, is that true? I thought that as long as I'm connecting to their SOAP service over https, the response back would automatically be encrypted.
If that's true, how can I run a cron job to be as https? My site is on a LAMP setup with cPanel access.
Thank you in advance for your help!
Your customers statement seems to be a little bit unclear in what he/she specifically means by "... connecting from an https adress" as there isn't any notion of the term "https adress" in the specs and https URLS only seem to make sense in the context of Request-URI s given in a https request.
Given this unclarity I'm only wild guessing. Nevertheless to me it seems your clients requirements might most probably not be connected to the http protocol but rather to establishing your TLS connection.
If your client is very sensitive in respect to the security of his system - which in fact if he intends to offer RPC requests might be a very good idea - he might not want to the whole world to be able to connect an encrypted connection to his machines and rely on any secondary authentication mechanism once the connection has been established.
As most users of the public internet don't have any certificates signed by a trusted authority this feature it isn't used out in the open wild but besides server authentication the TLS handshake protocol also provides a means of client authentication via client certificates (the relevant part being section 7 in RFC 5246 here. see: https://www.rfc-editor.org/rfc/rfc5246#section-7)
While in the absence of widely used client certificates web services usually rely on establishing an encryted connection to first to authenticate users by some kind of challange response test like querying for username and password your client might want to either additionally secure access to his machines by additionally requiring a valid client certificate or even - probably not the best idea - replace a second authorization like the one already mentioned above.
Nevertheless all this are nothing but some ideas that I came along with given the riddle in your question.
Most probably the best idea might be to just ask your client what he/she meant when saying "... connecting from an https adress"
Currently I am using Net::LDAP::Server to setup my server but it is not secure enough.
Is there any module or method so that I can setup a LDAP server over TLS or other secure connection?
I just found many information about how to connect to a secure ldap server, but cant found how to setup a secure ldap server.
Can anyone give some advices?
How does an LDAPS connection work
LDAPS is an unofficial protocol. It is to LDAP what HTTPS is to HTTP, namely the exact same protocol (but in this case LDAPv2 or LDAPv3) running over a secured SSL ("Secure Socket Layer") connection to port 636 (by default).
Not all servers will be configured to listen for LDAPS connections, but if they do, it will commonly be on a different port from the normal plain text LDAP port.
Using LDAPS can potentially solve the vulnerabilities described above, but you should be aware that simply "using" SSL is not a magic bullet that automatically makes your system "secure".
First of all, LDAPS can solve the problem of verifying that you are connected to the correct server. When the client and server connect, they perform a special SSL 'handshake', part of which involves the server and client exchanging cryptographic keys, which are described using X.509 certificates. If the client wishes to confirm that it is connected to the correct server, all it needs to do is verify the server's certificate which is sent in the handshake. This is done in two ways:
check that the certificate is signed (trusted) by someone that you trust, and that the certificate hasn't been revoked. For instance, the server's certificate may have been signed by Verisign (www.verisign.com), and you decide that you want to trust Verisign to sign legitimate certificates.
check that the least-significant cn RDN in the server's certificate's DN is the fully-qualified hostname of the hostname that you connected to when creating the LDAPS object. For example if the server is , then the RDN to check is cn=ldap.example.com.
You can do this by using the cafile and capath options when creating a Net::LDAPS object, and by setting the verify option to 'require'.
To prevent hackers 'sniffing' passwords and other information on your connection, you also have to make sure the encryption algorithm used by the SSL connection is good enough. This is also something that gets decided by the SSL handshake - if the client and server cannot agree on an acceptable algorithm the connection is not made.
Net::LDAPS will by default use all the algorithms built into your copy of OpenSSL, except for ones considered to use "low" strength encryption, and those using export strength encryption. You can override this when you create the Net::LDAPS object using the 'ciphers' option.
Once you've made the secure connection, you should also check that the encryption algorithm that is actually being used is one that you find acceptable. Broken servers have been observed in the field which 'fail over' and give you an unencrypted connection, so you ought to check for that.
How does LDAP and TLS work
SSL is a good solution to many network security problems, but it is not a standard. The IETF corrected some defects in the SSL mechanism and published a standard called RFC 2246 which describes TLS ("Transport Layer Security"), which is simply a cleaned up and standardized version of SSL.
You can only use TLS with an LDAPv3 server. That is because the standard (RFC 2830) for LDAP and TLS requires that the normal LDAP connection (ie., on port 389) can be switched on demand from plain text into a TLS connection. The switching mechanism uses a special extended LDAP operation, and since these are not legal in LDAPv2, you can only switch to TLS on an LDAPv3 connection.
So the way you use TLS with LDAPv3 is that you create your normal LDAPv3 connection using Net::LDAP::new(), and then you perform the switch using Net::LDAP::start_tls(). The start_tls() method takes pretty much the same arguments as Net::LDAPS::new(), so check above for details.
Well, perhaps LDAPS is not an RFC but to say it is not a standard or secure is certainly a stretch.
LDAPS is supported by ALL LDAP Server Vendors.
LDAPS is at least as secure as HTTPS.
As with ALL SSL (or TLS) the security weak points are how the certificates are handled.
Certainly LDAPS is more supported by LDAP server vendors and clients than is TLS. Active Directory as one example, does not support TLS. Querying the rootDSE for the supportedExtention 1.3.6.1.4.1.1466.20037 will (should) show if TLS is supported on any particular LDAP server.
We have some examples at:
http://ldapwiki.willeke.com/wiki/Perl%20LDAP%20Samples.
I'm trying to connect to gmail using a simple java program (like this one). But my question is:
Is there a way to do this with encrypted password and not the real password, for security reasons of course!! something like how we do in java-Oracle db ?
By default, the only authentication mechanism for IMAP is the LOGIN command, which takes an unencrypted username and password. You can add an encryption layer on top of it, either by connecting via IMAPs or starting a TLS layer via the STARTTLS command, but it still requires the client to know the cleartext password.
A server can optionally also provide SASL authentication methods invokable via the AUTHENTICATE command. The server advertises which SASL mechanisms it supports in its response to the CAPABILITY command. For instance, if the server includes the capability "AUTH=PLAIN", the client can use the PLAIN SASL authentication method via the AUTHENTICATE PLAIN IMAP command.
Gmail supports only one SASL authentication mechanism, XOAUTH:
C: 1 capability
S: * CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA XLIST CHILDREN XYZZY
SASL-IR AUTH=XOAUTH
S: 1 OK Thats all she wrote! dv32if2169247ibb.17
XOAUTH is a nonstandard SASL authentication mechanism using OAuth. (The leading 'X' means it's not standardized.) Google has published a document defining the XOAUTH SASL mechanism. They've also provided a google-mail-xoauth-tools package, which includes sample code showing how to use JavaMail with Gmail via XOAUTH.