I am new to LDAP and I am wondering if attribtue names like "maxPwdAge" and "pwdLastSet" are constant attribute names for LDAP, not just AD?
The reason that I want to know this is because I want to write a program to calculate password expiration time for all systems that use LDAP. If the names are not constant across systems, it might be pretty complicate for me.
pwdLastReset is peculiar to Active Directory as far as I know.
pwdMaxAge comes from a Internet Draft 'LDAP Password Policy', which is the step before an RFC, which technically expired years ago but which is nevertheless implemented by a number of LDAP servers. In OpenLDAP you have to add the ppolicy overlay to get the password-policy attributes to appear.
You should also note that you may not have access to the pwdLastReset attribute, and that pwdMaxAge is not an attribute of the user at all: it is an attribute of the policy entry, which you may not have access to either.
No. These is no universal standard to determine when a password expires.
As #EJP mentioned, there is a Internet Draft 'LDAP Password Policy' that has been implemented to some levels for several LDAP server implementations but it is not universal.
-jim
Related
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 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.
A user's password and salt determine the Kerberos keys generated by ktpass. I have noticed that ktpass sometimes changes the user's salt, but other times it does not. I was able to discover the salt by capturing a packet trace of a kinit. The salt appears to be generated based on the Kerberos realm and the userPrincipalName. However, it's not this simple. If the UPN is later updated manually, the salt is not updated. (I suspect that whether the /mapop option is specified may play a role.)
In what circumstances does ktpass set the user's salt?
How is the salt determined?
Is the salt stored in AD, or just in the KDCs?
Is there a straightforward way to read the current value of the salt?
Is there a way to manually change the salt?
In Microsoft Windows Active Directory, which has used Kerberos v5 since its inception in Windows 2000, the ktpass command sets the salt automatically. The salt is always used in Kerberos v5. In Kerberos v4, a salt was never used.
The complete principal name (including the realm) is used as the salt, e.g., accountname/somedomain.com#SOMEDOMAIN.COM, which is then paired with the encrypted hash of the password to absolutely ensure the result is unique throughout the AD forest.
As mentioned, the salt is the complete principal name (including the realm). It is stored in the ntds.dit file, which is the Active Directory database. The KDC get spun up in a process spawned by by kdcsvc.dll - and it relates to the values stored in ntds.dit. So while the KDC and AD database are not one and the same inside the runtime environment, they are, so to speak, "joined at the hip". I think when the domain controller shuts down, all the important elements within the KDC is persisted inside of ntds.dit. Microsoft does not provide exact details on how this is done. I have looked extensively, and my partial knowledge is drawn from careful study and inferences made from bits and pieces of articles found on the web. Note that the ntds.dit database is also the LDAP database. It is also the DNS database, if DNS is AD-integrated. All these protocols working together, plus a few more, form "Active Directory".
Open up Active Directory Users and Computers, go to the Account tab. The "user logon name" is the most straightforward way to "read" the salt. You don't see the realm name concatenated with it right there but it is implied. The SPN, if also defined, is listed in a straightforward way like you are looking for under the Attribute Editor tab (look for servicePrincipalName). Make sure you have View > Advanced Features selected in order to expose this tab. A corresponding UPN will also be listed lower down in this same section, in the manner that looks exactly like: accountname/somedomain.com#SOMEDOMAIN.COM.
When you change the account name on the AD Account tab, you have just changed the salt. Note if there is a keytab out there tied to this AD account, you will have just invalidated it, as its secret key inside is a concantaention of the password hash and the salt. When either the salt or the password changes, then the keys will no longer match between the AD account and that inside the keytab. You will have to re-generate it at this point.
Makes sense? This is really a field explanation. To learn more about Kerberos as it relates to AD, start here: Kerberos Survival Guide
There is a slightly easier way to read the current salt value (it is not really straightforward but at least no paket tracing is required):
Install MIT Kerberos for Windows
Open a PowerShell and run:
$env:KRB5_TRACE="kinit-trace.log"
'C:\Program Files\MIT\Kerberos\bin\kinit.exe' -fV UPN-or-USER#REALM
Get-Content $env:KRB5_TRACE | Select-String "salt"
rm $env:KRB5_TRACE
I assume here that MIT Kerberos is installed at its default location. If not you need to adjust the path name in the second command.
This solution was originally suggested here on Stackoverflow for Linux by user Spezieh.
I thought I understand how Kerberos works, now I am not sure at all.
We have a problem with Kerberos authentication on a 3rd party server with Windows Active Directory. The server support is insisting that what they call "kerberos server" passes additional information somehow, namely fields identified as uid and email, and I need to confirm that they are indeed "sent" by the server before they can help any further. I read "kerberos server" as the KDC, which "sends" information by placing it into the TGT, and the uid may be the good old UPN, except I do not understand why I am asked to confirm it is really there. But what is the email attribute?
I even read the whole RFC4210, but could not find any possible place for additional info in any of the tickets. In general, 1.5.2 talks about extending the protocol, but in the very abstract manner. There are also KRB_SAFE and KRB_PRIV messages, that can be used to pass arbitrary octet strings (3.4, 3.5), but no step towards defining their structure is done in the standard. There is also padata extension, that 5.2.7 notes have also been used as a typed hole with which to extend protocol exchanges with the KDC., but this seems sent one-way. And nowhere the RFC seem to talk about additional identified fields that the authentication server can attach to the ticket.
My question is thus bifold:
Theoretical: how additional attributes are passed in Kerberos, presumably in an interoperable way (not e. g. Active Directory extensions)? What am I being asked to confirm?
Practical, if anyone can help with that: how to track what is placed by the AD into these attributes?
The server support is very lousy at telling you what they really want to have. Here is what you need: You want the KDC to send you PAC data with the generated service ticket. Here is Microsoft's reference: https://msdn.microsoft.com/en-us/library/cc237917.aspx.
How to verify? You need the a keytab for the account which is accepting the security context. Configure that with Wireshark, log all traffic. You should see the TGS-REP for the service you'd like to use. Expand it, when the keytab is fine, you will see the decrypted information. Somewhere down below, you should see the Authorization Data fields, type 1 (AD-IF-RELEVANT). That is an ASN.1-encoded sequence of elements. Even element position describes the sub type, odd element position the octet string. In that octet string is again an ASN.1-encoded suquence with type 128 (AD-WIN2K-PAC) and that is the PAC data. Unfortunately, Wireshark can decode upto level one only. The request is an opaque byte buffer. I have minimal, working (though incomplete) Java implementation of the PAC data decryption.
The email value is not included in that structure but what you have is the RID KERB_VALIDATION_INFO structure and the userPrincipalName in the UPN_DNS_INFO structure. The latter is extremely easy to decode.
First check via LDAP that for the desired client account userAccountControl does not has the NA field set.
Godspeed.
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.