I am using JNDI framework to interact with various LDAP servers specifically for Sun one LDAP, I am observing the following:
Use case: If Administrator resets password of any user in Sun-One LDAP server then passwordMustChange attribute is set to "on". As a result user has to change his/her password on next logon. This is what documented.
I am performing same action through JAVA code using JNDI. I observed that this attribute is set to "on" successfully. So programming logic is correct.
But when I logon with that user on LDAP server, it doesn't give any error or pop saying that password has expired and please change your password.
The same use case works as expected in case of Active Directory (AD ) servers
In case of AD, we need to set pwdLastSet to 0. It works and system asks to change password on next logon.
On contrary, same use case does not work for any LDAP flavour such as Sun-One LDAP, ADAM, or Open LDAP.
Please let me know if anybody has observed such issue and suggest me how to fix this.
You're setting it in the wrong place. passwordMustChange is an attribute of the policy, not of a user. It means that if you set the operational attribute pwdReset for any user, he must change his password on next login, and that is advised via a response control when he does so.
That in turn means you must use the password-policy request control when binding a user, and check the response control. It also means that you must use the change-password extended operation when changing the password, rather than just rewriting the attribute.
This also explains why you thought you had to add objectClass=passwordPolicy to the user entry. You don't. You have to define a separate policy object containing a value for passswordMustChange and the other policy attributes, and specify that in the configuration as default policy, or in the user entry as his specific policy if you're going that far.
You need to reread the documentation and distinguish clearly between policy attributes and user operational attributes. They're listed separately.
What code are you using for the extended operation and request/response controls? I had to write mine. I posted it on the Sun Java forums several years ago: is it that code? Just curious.
Unfortunately there is no standard for this kind of feature (there's an internet draft, expired and which is partially implemented in different servers).
Depending on your versions of Sun Directory Server, there are different ways to do this (SunDS 6.x introduced a new password policy based on the Internet Draft).
With 5.x, I seem to recall that the passwordExpirationTime would take a specific value when the password is expired. The server will return a PasswordExpired Control part of the Bind response saying that it has expired.
With 6.x and beyond, the pwdReset operational attribute is set to true. The server will either return the PasswordExpired Control, or a PwdPolicyControl response if you've set the PwdPolicyControl request in the Bind request.
Related
Is there any expected/standardized behavior for an app that authenticates via LDAP, when one of its registered users has its DN changed? (Or more generally, when their effective principal changes, which seems to commonly be their DN. I'll say "principal" instead from here, though I usually think "DN".)
Here's an example from Gitlab running into this issue: https://gitlab.com/gitlab-org/gitlab-foss/issues/993
In their case (based on the commit linked in that issue) they seem to address this by using multiple attributes to identify users instead of a single one, so that a single change doesn't prevent them from mapping back to the same LDAP user.
It seems to me the available options would be:
Don't try to prevent the issue but provide some method to change the principal stored (either in-app or via DB modifications)
Try to prevent the issue by picking (automatically or manually by user) a better, static user attribute to use as principal
Try to mitigate the issue by cross-referencing multiple attributes, as in the above links
Which of these would be the expected/"best" approach here, if any?
The requirement is to find user password expiration time.
Now in ldap, you enforce expiration through password policy.
The password policy attribute pwdMaxAge specifies after how many seconds from the time the password was changed does the password expire.
ldap password policy
The moment you change/create user password, the operational attribute pwdChangedTime gets added with the timestamp.
Sadly, ldap does not add any operational attribute for the expiration time, it's something we need to calculate, by doing a pwdChangedTime + pwdMaxAge < current_time
In your mods-enabled/ldap file you can fetch the pwdChangedTime attribute. Cool! But how do I fetch pwdMaxAge attribute. This file only has structure for users, groups, profiles, clients but not for the password policy. raddb mods-available details here.
(I can do this programmatically, by writing code/script for fetching these attributes using cli and then doing my manipulation, but is it possible doing this through the config? Coz, if you look at it, this expiration time is something related to user attribute and there should be a way to return it along with bare minimum user data like name and organization that we return)
Thanks!
There is no such operational attribute pwdMaxAge in the user's entry.
The password expiry warning during checking the password is returned by the server in a response control if the client sends the bind request with the appropriate request control (see draft-behera-ldap-password-policy, section 6.1 and 6.2).
This means that the LDAP client (FreeRADIUS in your case) has to support this. Furthermore all intermediate components (RADIUS server, Wifi access point, etc.) have to propely handle the response and return some useful information up the chain to the user. In practice this does not really work.
Therefore I'd recommend to send password expiry warning via e-mail. There are ready-to-use scripts out there like checkLdapPwdExpiration.sh provided by LDAP Tool Box project.
In my Java web application,when a user gets logged in,i store the user name and other details in session as follows,
session.setAttribute("userName",username);
I am using ExtJs4 for UI.How to get the session variables in extJs?
Thanks
I can second #Geronimo approach. You need to get user Id and/or permissions when you authenticate the user. However...
You can't rely just on the username/permissions that you store somewhere in your JS code because it can't be easily spoofed. If you present user with some information that can be different for different levels of access you still need to do server side validation of the user identity.
You can't get session variables off the server web container using javascript only.
I do the same thing (storing userId as a session variable in java). I use Ext.Request to perform an Ajax request to a java servlet to get it (along with other data about the user like permission settings for the webapp to enable or disable features they wouldn't be able to use).
EDIT:
I second sha's answer also, the only reason I pass the authentication information back to the client is for cosmetic reasons - so that user doesn't think he can use a feature in javascript that would be denied by my server side authentication. If he were to spoof the userId or permissions and try to use the feature, the real authentication on the server side would stop him.
I understand that the question has been asked for a long time ago, but despite the large number of views and the absence of an plain answer, I decided to offer this answer:
Assume that the session variable is registered like /index.php?PHPSESSID=9ebca8bd62c830d3e79272b4f585ff8f
In this case, you can get the variable PHPSESSID through JS object "location" and transform it through Ext.Object.fromQueryString()
So:
console.log( Ext.Object.fromQueryString( location.search ) );
will prepare PHPSESSID variable for your needs.
When a user account gets locked in an LDAP server which LDAP standard attribute is being modified? Is that standard LDAP one or specific to the server (i.e. Active Director/ Novell etc)?
There is a very old draft , but I do not think any work has been done on this in some time. Also, Sun and UnboundID directory server support the Account Usable request and response controls.
Check the User-Account-Control Attribute, described here: http://msdn.microsoft.com/en-us/library/ms680832(v=vs.85).aspx
The draft Terry Gardner referred to is mostly implemented in OpenLDAP, so if that's what you're using that covers it. Specifically the attribute is pwdLockedTime. It is either absent or set to the time the account was locked. It is an operational attribute so you have to request it specifically or via "+".
OK, so I'm quite new to the whole world of claims aware applications. I was able to get up and running very quickly using Azure ACS but it's been a bit of a different story when trying to use ADFS 2.0 as the identity provider (I want to actually use it as a federated provider, but for the time being I'm just trying to get a sample running using it as an identity provider).
I've been looking at the guides here and have tried to follow the AD FS 2.0 Federation with a WIF Application Step-by-Step Guide guide listed there. It takes you through setting up ADFS 2.0 along with a little claims aware sample application that you can use just to view the claims that are getting sent through.
So I can get that up and running, passing through the claims defined in the guide (just the windows account name). The problem is when I try to add any more. I can go to the relying party application in the ADFS GUI and add an Issuance Transform Rule, using the Pass Through or Filter Incoming Claim rule template. However, when I run my application, unless the added claim type is Name, it won't pass the claim through to my application.
One of the ones that I wanted passed through was the email address for the user who logged in to the application. So I added a rule to pass through the email address, then updated the web.config of the sample application to uncomment this line under the claimTypeRequired section:
<claimType type="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" optional="false" />
Note that I'm setting it as non-optional. I also updated the federation metadata of the application to add in the following:
<auth:ClaimType Uri="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" Optional="false" xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706" />
I then went into the ADFS GUI, went to the Relying Party Trusts and selected Update from Federation Metadata on my sample application. So it now lists the email as one of the accepted claims.
I then went into the Claims Provider Trusts and added the email claim rule into the Acceptance Transform Rules for the Active Directory provider trust (the only one listed).
When I run the app however, it's not passing through the email claim (or any others that I try). Can somebody tell me what I'm missing here?
I should also note, I ran a test to change my application to only accept the email claim rule, and not only did it not pass through the email, but it's still passing through the Windows Account Name and the Name claims, despite the fact that I don't even list them as accepted claims for my application.
If anybody could point out where I'm going drastically wrong here, it would be seriously appreciated.
After enabling logging as per the blog post before, here are the relevant entries from the log:
Event ID 1000, "Input claims of calling principal included in details":
So you can see, the information that I'm requesting is quite clearly missing. I have the logging output set to verbose but there's really nothing of any other interest. You'll see trace records for the NETWORK SERVICE user (with the same set of claims), but nothing striking. All the log entries are informational, there aren't any errors.
If you using ADFS as Identity Provider and want it to issue an email claim, then you have to use Send LDAP Attributes as Claims or a Custom Claim Rule which access AD as the attribute store and issues an email claim. Pass through is used on the incoming claims, assuming the user is already authenticated somewhere. In case of Windows Authentication Windows account name is issued from the Kerberos token and that's why you have to pass it through, but others you have to issue.
Does Active Directory issue E-Mail Address claims? I'm not sure how to check this, but if it doesn't, it's irrelevant that you're passing them through. In this case, you'll want to try a "Send LDAP Attributes as Claims" rule; based on what I see in my ADFS instance, try mapping the "E-Mail-Addresses" attribute to an "E-Mail Address" claim.
I had to do something similar to get UPN claims to come over, in circumstances similar to yours. I'm not sure whether it will matter that the LDAP attribute is potentially plural.