is it possible tracking all authentication requests on AD Server? - active-directory

is it possible tracking all authentication requests on AD Server? no matter the requests go through LDAP, Kerberos or NTLM, and getting know the source IP address and account name?

That information is already in the Event Viewer on each of your domain controllers.
If you search online, you may be able to find some software that can be installed on each DC that will consolidate all that information for you to make it easier to look at and search. But I've never done that, so I can't recommend anything.

Related

Update O365 proxyAddresses via API

Using the Microsoft Graph API I need to be able to update the attribute proxyAddresses as part of our provisioning process to enable self-service password management for our end users.
I see that this attribute is read-only from the Graph API but as of 8 months ago MS was entertaining the possibility of making it RW. Does anyone have any color on this, has anyone found a workaround to this issue via API?
This isn't supported in either v1.0 or Beta at the moment but this is an open OverVoice request for this feature: Ability to update the user's email aliases (proxyAddresses attribute).
Also if you are working with bigger customers - usually you want to sync their identities from local Active Directory using AD Connect tool. In that case you should implement things and change proxyaddresses attribute in local AD, because it is the "identity authority" (means that you can't change it on cloud side and it must be done in on-prem AD).
So it could be workaround for problem you are trying to solve.
Also if it is cloud only (not synced) identity - you can use PowerShell to modify proxyaddresses attribute on users.
Here is documentation on how to do that - https://technet.microsoft.com/en-us/library/bb123794(v=exchg.160).aspx

Best practices when configuring relying party for on-premise authorization

I've created a website within the company that utilizes our active directory server to authenticate. I am concerned about security surrounding setting up relying parties with "localhost" domains.
I've pretty much followed this guide on setup. You'll notice about halfway down the page, there is a step to set up the development environment, localhost:44336 as a relying party.
I am concerned that someone could easily get the location of our federation metadata document, and simply roll their own project utilizing the same port and get access to our active directory. Is this a valid concern, or am I worrying over nothing? What would be a better alternative to having to use localhost in this configuration?
Yes it's safe. The metadata document only describes information about endpoints and about the token that active directory is issuing. It doesn't inherently have anything sensitive about it.
The actual authentication is still going to be handled by AD and unless the curious user already has a way to successfully authenticate against your AD then it's rather useless for him to hookup into that document.
Could they potentially create an app that uses your authentication protocol? Sure, but what would be the point if nobody can actually authenticate against it. Allowing this sort of behavior to happen is one of the points of ADFS.

Access outlook.com calendar using the software davmail

Using a mobile phone, it is easy to connect to an outlook.com account using s.outlook.com as server - as specified by microsoft link. I think access should be possible using the software davmail in a similar way, thus enabling users to access their online calendars via thunderbird/lightning.
What is the URL that davmail needs for this? Shouldn't it simply be a reformatted version of the address given above? NB: The combinations given at the davmail project's website I tried already. Research on the internet did not reveal the solution either. Who can help?
Thank you!
outlook.com exposes only the Exchange ActiveSync (EAS) protocol, while davmail needs the Exchange Web Service (EWS) protocol (or WebDAV).
So, as of today, and until outlook.com exposes EWS, this can not work.

Restricting URLs using Active Directory in Weblogic 10.3 - where to start?

We are looking to use an Active Directory server to restrict access to certain URLs in our Spring application on a Weblogic server and I have no idea where to start. The problem should be quite simple as I understand it, we have a simple app which has a number of URLs:
<root>/page1.do
<root>/page2.do
<root>/page3.do
etc.
And an Active Directory servers which lists the users in two groups, such as "Admin" and "User". We would like it so that based on the login information provided (no SSO required), anyone in "Admin" can access all pages, anyone in "User" can only access page2.do and page3.do.
I have absolutely no idea where to start and Google isn't being very forthcoming. I would have hoped that this is an easy task (add AD server to weblogic, set up a config file). Anyone have any experience with this and links to good places to get started or a summary of what we will need to do to get it working in this fashion?
Cheers
You should be able to easily use your AD as an Authentication Provider in your Weblogic server(s). Here is some documentation to get started on how to do the configuration:
http://download.oracle.com/docs/cd/E12840_01/wls/docs103/secmanage/atn.html#wp1198953
After that, you can configure security roles and security policies in order to control access to your server's resources. Again, some docs to get started: http://download.oracle.com/docs/cd/E13222_01/wls/docs81/secintro/concepts.html#1083616
If you prefer a good book to start with, here goes my suggestion: http://onjava.com/pub/a/onjava/excerpt/weblogic_chap17/index.html. Although somewhat old, this chapter covers pretty much everything you need to know.

Is it a good idea to use Active Directory user login to your application

I am developing a web based intranet for my company. I just want to know is it a good thing for users to login the application using the active directory login details or shall i create a login together with the application db.
If there is anything better that this please suggest. This is my first application development so need help from experienced people.
Generally it's a good idea to try and minimize the number of accounts people need to have.
So I'd definately try and use their active directory login.
Also if desireable, you can automatically log people into your application using various single sign on methods. (Either integrated into IIS, or other.).
This makes for a very usable application, as people always forget login details, and hate to login again to other systems.
Only use Active directory for your intranet, if you infrastructure supports it.
You question is phrased as if you think the user to type there password in again to login to the intranet site - they should not do this! have windows pass on the credentials automatically. This is pretty much built in to dotnet/iis/etc.
Also AD will add group management a privledges so you can restrict areas of you intranet to members of certain groups.
And you support team already have the tools to manage all this.
PS you can enable FireFox to auto log on via NTLM and it is one of the most requested features for Chrome too so don't let browser issues put you off
There are several pros using Active Directory authentication in the intranet.
Thoses are the main ones:
You want to to keep authentication stores number as low as possible
Using Active Directory, users who have their desktop in the domain (as they should) will be able to use Integrated Windows Authentication. They will be able to log in without having to type their password.
An Active Directory authentication mechanism probably exists for your language
More information:
http://msdn.microsoft.com/en-us/library/ms998358.aspx
If you create a separate login system, then your users have to remember 2 different logins. Why bother, when their "real" login is right at hand?
Less code for you to write and better integration into the wider system. And, who doesn't want FEWER passwords to remember.
Definitely go for the Active Directory option, or use Active Directory as an LDAP server if whatever language you're using doesn't directly support AD. Active Directory actually makes a pretty good LDAP server.
If there is anything better that this please suggest.
OpenID?...

Resources