I am currently trying to find out AD users password expiry date.
Using the methods described on numerous pages for e.g. here work fine until a user or group in AD is using a fine grained password policy that does not follow the users domain password policy.
I found a property called msDS-UserPasswordExpiryTimeComputed that figures that all out without trying to do any calculations.
This works well, until we are using a global catalog since this property is not replicated by default. When I attempting to replicate the msDS-UserPasswordExpiryTimeComputed property in my global catalog, I get the following error:
Is there anyway to replicate this property or is something wrong with my setup that is not allowing me to replicate this property? Is there a better way to calculate user password expiry to take into account the fine grained password policy?
I suspect you can't. I can't find any authoritative documentation saying it is not possible, but here are the reasons I think it's not possible:
The attribute is constructed, meaning it's not stored, but it's calculated at the time you ask for it.
The date depends on the policy on the domain, thus the server returning the data needs to know the policy on the domain of the user.
Since a GC may not be on the domain of the user you find, it may not have the information needed to be able to calculate the value.
As a workaround, you can just rebind to a DC to get the value. You didn't say which language you're working with, but usually you can take the path of the object you found, which will start with "GC://", and just replace that with "LDAP://". Then grab the msDS-UserPasswordExpiryTimeComputed value.
Related
Using Solr Basic auth plugin
How do you set permissions based on the "core"? Only want certain users to be able to access a certain core.
I thought that was the "collection" value, but that isn't it.
From my own experience trying to solve this exact issue a year ago - I'm unable to find the reference where I read this, but:
You can't limit access to a specific core through security.json - if you need to limit which users can access which sets of data, you'll have to use SolrCloud and the collections parameter.
You might be able to limit access by having a reverse proxy in front, but be aware that certain GET parameters could be used to switch the request handler back in the "old days" - but that might have been removed now (and not sure if you could switch cores in the same way).
You also have to use the path parameter to limit operations (i.e. to only allow a user to access /select or /replication etc.).
I have been assigned a task to export the AD Attributes than find out what systems are using these attributes. I have not had much luck in scripting or a tool that can provide just that. Is this feasible and if so how? I have already exported attributes. Just need to find what systems are using them.
This isn't possible with any reasonable accuracy, especially if "using" isn't defined for you.
The event logs on the domain controllers will tell you where login events are coming from, but only by IP. That doesn't tell you which application is authenticating. You would have to do monitoring on that computer and see which application is making the connection. But then the logs would be cluttered with connections made by Windows itself, or Exchange (if you use Exchange for email). It it would be very difficult to identify what is coming from an 3rd-party application rather than Windows itself.
Also, applications can request more information than they need. It's very easy when programming with LDAP to request every attribute for an object, even if you only intend to use one. For example, take this C# code:
var de = new DirectoryEntry("LDAP://example.com");
Console.WriteLine(de.Properties["name"].Value);
That only "uses" the name attribute. But because of the way LDAP works, it actually requests every non-constructed attribute that has a value. (there is a way to specifically ask for only one attribute, but you have to know that and use that)
So even if you could find logs saying that "this IP requested all of these attributes", and then figure out which application made that request, that doesn't mean it "used" all of those attributes.
I need help for my AD Integration.
I’m using Spiceworks for the system and there is a portion there for AD Integration.
The problem is that I need to sync two different OU’s
Base DN for LDAP search:
DC=dc1,DC=dc2
LDAP user filter:
(&(objectCategory=person)(|(ou=OU1)(ou=OU2)))
And its not working.
My AD Structure is
dc1.dc2
— OU1
— OU2
— OU3
dc1.dc2 is the top level.
OU1, OU2, OU3 are on the same level.
The reason is I don’t want to include OU3 in the syncing
LDAP filters are generally only applicable to attributes that are in the user entries.
If you want to include attributes that are part of the DN (the path to entries), you need to use extensible filters such as:
(&(objectCategory=person)(|(ou:dn:=OU1)(ou:dn:=OU2)))
Note that while this is standard LDAP filters, not all servers support this.
Active Directory doesn't support filters based on OU. In this instance, it's an "extensible match filter" that some LDAP implementations support, but not all (including AD). More info here.
By the way, you can't do a wildcard search on the distinguishedName, if you're tempted to try.
To be honest, this is why it's best to have all your "person" user accounts in one OU (maybe subdivided further down), groups in another, etc. In your case, if you can, it might be a good idea to move your "synching" account OUs under a new OU. If you have a enterprise environment, you will want to be careful there are no dependencies on the OU structure before making such a change. Or that you can identify any such dependencies and fix them before or at the time of making the change.
Otherwise, you'll need to make your searchbase the root of the domain. If you have other user account attributes you can use to search, such as department names or similar, that will work. If it's employee accounts, do they all have a common field that's populated, such as "employeeID" or "streetAddress" or something? Or do the accounts you want to exclude have a specific name format (such as all the service accounts starting with "SVC")? By combining things like that, you can generally get it pretty good.
Finally, for searching normal user accounts, a more efficient basic query is:
(samAccountType=805306368)
Your query of (objectCategory=person) returns User and Contact objects. The usual way to scope it property is (&(objectClass=user)(objectCategory=person)), but the two clauses makes it less efficient than my recommendation (which is using an indexed attribute as well).
I'm looking for a simple solution for a cooperative project where specimens will be mailed to me, and I would report several measurements back to the sender.
I need the originating site to fill out a form with some basic information (specimen ID, collection dates, shipment tracking #, etc). Then I need to let the site know I received the shipment - via the same form. Then, after some analytics, I need to report 3 numerical values (biomarker levels) back to the site.
Someone recommended REDCap for this project. I know I can do data collection with REDCap (the initial requisition form), but can I also report the values back with REDCap?
It appears I found the solution, by talking to a REDCap expert. In case someone is interested, here's basic outline:
Create two forms: one for requisiton, another one for reporting data back to user.
Invite REDCap users to my project and give them read-only rights to the second form.
Put other users in Data Access Groups, so they only can see the requisitions (and results) from their own group.
This might work, but I decided to not go this way. In REDCap, an user has all rights by default, and I would have to limit them. In my application there is too much potential for data breach due to mistake in assigning rights and DAGs.
Another solution would be to use REDCap with an email alert module enabled.
Configure a project with two forms:
One for the client to enter the information you need from them, and make that form anonymous - no user account needed, and collect an email address from them (to return results). For the example below let's call this form [request].
The second form will be for you to enter the biomarker levels and whatever else you need to. This form only needs to be viewable and editable by you. Let's call this [results].
Then, if you have the email alerts module enabled (and you'll have to speak with your REDCap administrators about that) you can configure it to automatically email someone with information contained in the record, and to set the logic by which the email is sent.
This solution and the one you were recommended are the same with respect to form design, but they differ in the way the results are shared with the requestor. This solution does not require the user to have an account to access the results. I personally think the other solution (with user roles and DAGs) is the better solution.
In a domain with AD Sites and Services configured is it possible to get the Site of a computer from LDAP? Is it stored as an attribute?
Unless this has changed over the last couple of years outside of my knowledge, there is not. Historically this was never done as AD site knowledge was ephemeral...the assumption was that computers move around so storing where they are is silly. Plus there was no global need for the knowledge.
You could of course add this. By this i mean, you could do something like, extend the schema with a new attribute for this and set a start-up script on your domain-joined machines to write this (if it has changed since they last wrote) to the directory. Obviously you'll want to test this well to ensure it doesn't create more problems than it solves...
On the Win32 point of view you've got the DsAddressToSiteNamesEx API. I don't know how to find it using pure LDAP.