You say that you "will collect user name and password of an end user and want to check against with windows azure active directory" - I am pretty sure this is NOT possible, and I know for sure it is not advisable. This is the opposite of the trend of approaches like OAuth where users can login on many applications using the same credentials (and the part coming up is critical) without ever revealing to those "many applications" their password.
This is the idea of Federated Authentication and is a more secure model than the older approaches of allowing all apps that you log in with to have direct access to your username and password. Typically in such a flow, assuming an existing Office 365 account, the new app you've created and configured to authenticate using O365 will REDIRECT the web browser of the user to O365 where the user types their O365 username and password in, and then agrees (one time) that it is okay for them to be used with this new app, then the browser will REDIRECT back to the app, with a security token with some claims in it. These claims will include the name, email address, and other things about the logged in user and are intended to be sufficient to identify the user in your app.
Same would go for authenticating with, say, Facebook or Google - your app will never directly see the user's password. It would even apply to logging into StackOverflow itself, so you've seen the workflow.