I'm getting some details from Active Directory via LDAP url, for this
ADsOpenObject in msdn library:
hRes = ADsOpenObject(pwszBindingString, pwszUSER, pwszPASS, ADS_SECURE_AUTHENTICATION,IID_IADs, (void**)&iads );
I'm having doubt about whether the given password will be encrypted or not while connecting the Domain Controller
This MSDN page says
Caution If a user name and password are specified without specifying authentication flags, the user name and password are transmitted over the network in plaintext, which is a security risk. Do not specify a user name and password without specifying authentication flags.
You are using the ADS_SECURE_AUTHENTICATION flag from the ADS_AUTHENTICATION_ENUM, which means:
Requests secure authentication. When this flag is set, the WinNT provider uses NT LAN Manager (NTLM) to authenticate the client. Active Directory will use Kerberos, and possibly NTLM, to authenticate the client. When the user name and password are NULL, ADSI binds to the object using the security context of the calling thread, which is either the security context of the user account under which the application is running or of the client user account that the calling thread represents.
Both NTLM and Kerberos are protocols that "encrypt" the password. If you want the username encrypted as well, then you need SSL (which requires that a certificate server is setup for the domain).
You can always use a packet sniffer to verify that the information is encrypted.
Related
I have a WSO2IS install in development configured with the OOTB PRIMARY user store and a secondary Active Directory user store. When signing in to WSO2IS Mgt Console I can sign in as an Active Directory user, but only if I provide the domain name like DEVUSERS/devadmin.
I have been experimenting with lots of different settings and I'm pretty sure I had it working at one point so I could sign in with either a PRIMARY user store user (admin) or a DEVUSERS Active Directory user without providing the domain name, but can't reproduce it now.
I should add that I really don't care if DEVUSERS can sign in to mgt console. I just need to authenticate them when they sign in to my web application that uses OIDC to have WSO2IS handle the authentication. I have a Service Provider configured for my web application connection.
I have tried replacing the OOTB PRIMARY user store with my DEVUSERS user store. With that setup users can sign in to my application without providing domain name, so that part works fine. But, the DEVUSERS user I am using to connect the user store (i.e. ConnectionName) doesn't have the 'admin' permission, so can't perform some mgt console functions.
You can log in to the IS with any user in primary or secondary user store either specifying a domain name or without a domain name.
Once you try to log in to the system by specifying the domain, IS will look at the specified domain user store to authenticate the user. Otherwise, it will go through all the define user stores starting from primary user store.
In your case, the devadmin user may be exisiting in the primary user store with another password.
I am facing a problem understanding the reason why to use mod_auth_kerb for authentication to a Kerberos server.
I am developing a website using Django + mod_wsgi + Apache .
The first page of my website asks the user to enter username/password and one of my Django app will take the username/password and use Python kerberos module to authenticate the user to the kerberos server.
Where do I need to use mod_auth_kerb here ?
I understand that I will have the power to use the username/password to my advantage,is this the reason of using mod_auth_kerb ?
mod_auth_kerb can do two things:
Prompt the user for a username and password via HTTP Basic and validate them using Kerberos on the server side, or
Allow the browser to authenticate using Kerberos on both sides, via HTTP Negotiate. If the client supports Kerberos, this provides single-signon: the client automatically authenticates to the server via the Kerberos system without prompting for a password, via credentials obtained when the user logged in.
You are doing #1 in your application. It might be useful to move that into Apache, where it can be done once consistently for all apps. #2 you're not doing at all, but it's only useful in an environment in which Kerberos infrastructure is available.
A word of warning: I don't know about the "Python kerberos module," but it's very possible that it is not doing password validation securely. Many things which claim to do this do the equivalent of "kinit": they use the username and password to obtain an initial Kerberos credential (TGT), and claim success if it appears to work. The problem is that they have asked a third party (the Kerberos authentication server (key distribution center), or KDC) to validate the password -- but they have not checked that they are actually talking to a real KDC. They might just have received a message from the same user who gave them the password, and the message of course says, "the password is right." In order to do this properly the verifier needs its own identity in the Kerberos realm (a "principal"), and to take the extra step of using the TGT to obtain a ticket for itself and verifying it; this ensures that the reply is from a genuine KDC.
Another common way of doing this, if your KDCs are Windows domain controllers, is to use LDAP: connect to a domain controller via LDAP and authenticate with the password; the DC will check the password against Kerberos itself. Of course, you have the same problem: you need to verify that you're talking to a genuine domain controller -- but you can do that with TLS via certificates, which may be easier.
I'm working on creating a web service to expose customer authentication to external vendors. In this case the vendor is a wifi-provider.
My question is if they (the vendor) is POSTing a login and password to a service over SSL, is it a good idea to authenticate the vendor (to access the API) first? I can see both sides of the argument.
EDIT
The end user will be entering their credentials on the vendor's side (ie on the vendor's login page)
Vendors should never see your users' credentials. Instead the login form that the user enters their credentials on should submit directly to your server. If the username and password is correct it should redirect back to the vendor's site with a ticket id. The vendor's server can then take that ticket and ask your service if it's a valid ticket and for any relevant user information.
I am writing a simple protocol for a basic chat program.
my question is: once the client has authenticated by providing username and password, should I also ask the client to provide a token in it's following packets? or is it sufficient to keep it's authentication status in a table at server and never expect the client to prove it till it disconnects and reconnects?
You should not demand for authentication for any further messages after client has given correct credentials. If your suspect, each and every message should contain authentication information, and in this implementation you need not to authenticate via "login" - just demand security information on each message.
After successful login, the only case you may demand user credentials is when updating the client's information (by client itself), which includes changing password and other "user" information. You must ask for password when "change password" request is initiated.
Ensure that authentication is having some encryption attached, so that no one can intercept the message. You may also have some key (like few bytes string), that you can validate for each incoming message to ensure the message is coming from correct client (this as per your original design, not for the alternate design I given in first paragraph).
We have an API that will be only used by our new website for now. I would like to get an input how what stackoverflowers think about the security in place for this api.
1)SSL protected
2)When logging in, the user's "IP" is sent as well as user and password. The API is then attached to the session and the session token is sent back. Whenever the next call is made, the userID, session and ip are passed. Then the userID is verified with the right sessiontoken and ip and if its good then the method is carried out.
3)The webservice itself is protected to allow access only from the ip where the server is being hosted.
Thanks,
Faisal Abid
I don't see why an ip address is passed. This should be pulled from the TCP socket and there for cannot be spoofed or otherwise influenced by an attacker.
The session id should be a Cryptographic Nonce and ideally you would be using a session handler already available in your platform. There is no sense in re-inventing the wheel.