Is there any way to provide two factor authentication for Microsoft Outlook client. It may use ISA server or any other. Basically 2-factor authentication is possible for OWA but I haveb't been able to find a way to implement it for Microsoft Outlook.
In order for that to work, you would have to change the authentication method in Exchange. This is easy to do in packages like postfix a la:http://www.wikidsystems.com/support/wikid-support-center/how-to/how-to-configure-webmail-for-wikid-strong-authentication/, however, I bet it would a lot harder for Exchange.
Related
I've become somewhat familiar with the concept and management of two factor authentication. Many suggestions for using it point to using a third party tool such as Google Authenticator.
However, what are some of the security concerns with a simpler 'home brew' approach, such as:
first requiring a username/password, then once that's authenticated to open a second form requiring a specific piece of information sent to the person's email (and/or providing a QR code scheme, and/or SMS message)?
In a legacy Windows Forms application, users are now identified by an LDAP query. In essence, they scan their badge (barcode) and the application runs an LDAP query to get user attributes.
I know, from a security perspective, this is bad, but usability is more important than security in this case (we're talking about machine operators and they just need to sign-in / sign-off).
Now, we would like to move to a web-based architecture and the simplest thing would be to run the LDAP queries from the back-end to achieve the same.
However, I was wondering if we could switch to a more secure solution using ADFS and RFID/NFC badges, but I can't find any existing implementation. (I'm not looking for 2FA).
So, I'm trying SO, knowing this question can result in opinionated answers: if anyone has experience with a similar use-case, please stand up.
ADFS doesn't do this OOTB.
You could write a custom authentication feature or use the MFA server.
I see you don't want MFA but if you look at the screenshot, it does more than MFA.
I am trying to use the new .NET methods of sending email (System.Net.Mail), but I have various troubles along the way. My VB.NET app allows users to gather info and email it out based on the smtp server specs they set. Current issues are sending using STARTTLS (i think thats what its called) and doing things like authenticating via POP before being granted the ability to send.
I have had great reliability using CDO to deliver mail in the past as a part of a vbscript I wrote, and am going to look at integrating that over Net.Mail.
Is there a problem with using CDO to deliver email, over current .NET methods? Is it deprecated, or bad practice? Is there any limitation based on current email technology?
Am I totally going to wrong direction, and should instead, use a precompiled SMTP Mail application I can drop in as part of my application? I have seen people do this over writing their own code to deliver mail. If you like this method, what are some good choices?
I have made a simple WCF-REST-service, published it to Azure and activated SSL with a X.509-certificate.
I'd like to setup some authentication for this service as well. I could solve this very easily by sending a credentials-header in clear text since all traffic is now encrypted, but I am planning to use some kind of federated authentication instead so that users can take advantage of Single Sign-On.
This field is relatively new and yet seems to already be littered with obsolete technology, making it difficult for someone with little experience to find current best practices and solid toolsets. I'm hoping somebody with significant experience can provide some insight and give us all an up-to-date jumpstart.
What are the modern, state-of-the-art options for federated authentication?
Is OpenId the only technology for this?
Is it difficult to implement SSO?
Can a relatively inexperienced yet reasonably intelligent developer implement this based off a few tutorials? Or are the underlying technologies too complex, making a third-party API/framework more desirable? (like DotNetOpenAuth)
For Azure and WCF specifically, is "Windows Azure Active Directory Access Control" really necessary, or would that be like swatting a fly with a sledgehammer?
Authentication, Authorization and identity federation are HUGELY complex subjects and should not be taken lightly. The reason security is a big, complex problem is that its extraordinarily hard to get right!
If you don't already have a great deal of experience in internet identity & security, don't try and roll your own auth mechanism: Correctly and securely implementing an authentication mechanism is very, VERY hard.
For example, in your scenario above, you've not accounted for ensuring that the creds you pass in the HTTP header are anonymized for each site you want to present them to and that they expire after a period of time, that they cannot be replayed, that they cannot be synthesized by a malicious 3rd party, etc.
I strongly encourage you to use a pre-existing authn mechanism and supporting framework. In fact, since you're an Azure user, the easiest way to add end-user identity federation to your site is to use the new authn features of Windows Azure Mobile Services
If you still want to learn more about identity and identity federation, I encourage you to research this subject before choosing the right type of authentication to use:
Start with A Guide to Claims-Based Identity and Access Control (2nd Edition). This will give you most of the background and knowledge necessary to understand this subject sufficiently to make sound decisions.
Once you've got a good grip on this subject, I recommend reading everything that Vittorio Bertocci has written over at http://cloudidentity.com.
HTH.
I have an AIR application and would like to connect to an LDAP server to obtain some information for a particular user.
The url is something like ldap://ldapservername:389/
I would like to pass the userid/Name as the parameter and hope to retrieve the Full Name, Email address etc.
Can you please provide suggestions regarding implementing this? A Windows specific solution is also fine with me.
Adobe AIR does not have built-in support for LDAP. All online examples go through a server for LDAP integration.
Sample: Performing an LDAP query for role resolution
http://www.adobe.com/devnet/livecycle/articles/perform_ldap_resolution.html
Short of using a server, you're limited to two options, neither of which is good.
Completely re-implement the LDAP protocol in AIR. I think this is feasible, but is a huge undertaking. With Alchemy you theoretically could recompile an existing C library to work with AIR, but I don't know how well that will work for this particular use-case. Plus it's a research project, not production ready.
Embed a native application. With AIR 2.0 you can include a native application written in C or .NET or whatever and launch it to perform your LDAP calls. The only way to communicate with this other process is through stdin/stdout so it's not easy to transfer complex/typed data, but it's feasible.
AIR is not suited for all applications. If all of your application's requirements can be fulfilled within AIR's API, then it's great. But if you need to do something not directly supported by AIR and don't have a server component, you're better off not using AIR.
You will probably need to do the usual LDAP stuff. Either start with the full DN of the user (uncommon) or search for it.
Bind to the LDAP directory as a proxy user, or as an anonymous bind. Query for ATTR=VALUE where ATTR is something you define as the unique value in the directory. Traditionally this is uid in LDAP servers. For Active Directory probably would be better to search for ATTR of sAMAccountName. Keep this as a setup parameter for the admin, since it will make it easier on different LDAP backend servers.
It might be mail, and the login value the user would enter is their email address. Depends on the use case. But leave it configurable to be flexible.
Then the search should return one value, with a full DN, then you want to bind as that user with the full DN and the provided password. I like the approach of binding as the user, instead of comparing the password, since then you increment any Last Login attributes, or the like, making it easier to detect account inactivity from the directory administrators perspective.