For a school I implemented eduroam two years ago and from time to time we add new students in the AD.
Five days ago I added 40 more new students but I changed the CN's (or what in New-ADUser is called "-Name") format:
from "name.surname" to "SURNAME, NAME" (quotes excluded), hence
earlier it was
CN=name.surname, OU=CLASS_A, OU=STUDENTS, DC...
now it is
CN=SURNAME, NAME, OU=CLASS_A, OU=STUDENTS, DC...
an eduroam's username normally is <string with no blanks>#<yourschool>.<tld> so that the RADIUS proxies can route the auth request based on #<yourschool>.<tld> , So I must keep such a format.
Now, the new users cannot be authenticated anymore by NPS.
All the tests I ran back my thesis (i.e. that NPS uses CN to authenticate) but I cannot find any Microsoft document that states that.
Could anybody share the link to such doc?
is it a way to change the check from CN (if proved by answer of point 1)) to another user's recor like sAMAccountNAme or UPN?
I'm sure I'm touching something deep in AD but I hope somebody has tripped into this issue and has found a answer.
TIA
P.S. I guess the alternative would be to use FreeRADIUS but I would rather explore the options to still make within NPS/AD
• Please check the Windows Server event security log for more details on the issue for NPS authentication because that might shed some more light on the actual issue that you might be facing. Till then, please clear the cache and temporary files from the server and restart the whole infrastructure regarding NPS, i.e., domain controller, NPS Server, Access points and other related devices through which users can login through NPS.
• Once restarted, please try to authenticate any allowed user through NPS once again and check. Also, as you are using NPS as a radius server proxy, please check for the attribute manipulation rules for message forwarding since the CNs are changed in their order/format in your AD. Specifically, regarding the username which is provided by the access client and is included by the NAS in the Radius access-request message. The value of this attribute is a character string that typically contains a realm name and a user account name.
• To correctly replace or convert realm names in the username of a connection request, you must configure attribute manipulation rules for the User-Name attribute on the appropriate connection request policy.
Also, find the below links regarding your query whether which attribute you can use to authenticate in case of NPS. In it, it clearly stated that user principal name should be used as an attribute as a best practice: -
https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-best-practices#performance-tuning-nps
https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-best-practices#using-nps-in-large-organizations
Please check the below documentation link for your condition: -
https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-plan-proxy#key-steps-3
Related
"Issue description copied..."
I'm building a partner connector, which relies on a user name and password to connect to database (very similar to the existing Postgres / MySQL connectors provided by Google). In order to verify the credentials, I also need the database host information to be present in addition to username and password and this is the base of my problem.
The Google build connectors conveniently are allowed to collect user credentials and the database related information at the same time. Unfortunately, that doesn't seem to be the case for partner connectors as stated in the requirements
Point 5 "Use appropriate authentication method in getAuthType(). Do not request credentials via getConfig()."
The authentication itself happens before any other configuration details are known (there is just a dialog for username and password) and there doesn't seem to be a way to request additional information on the authentication screen itself. Once the credentials have been entered, the verification also happens immediately, before the configuration is being shown in the next step.
Once credentials are validated successfully, Datastudio then assumes the schema and data can be requested.This excludes the option of a dummy confirmation, because there doesn't seem to be a way to tell credentials are invalid and need to be changed after checking the other configuration details on the next screen.
That makes me unsure, how to determine valid credentials in my use case as I need to know the variable endpoint to authenticate against. I definitely want to avoid storing any user credentials myself in an external database, because this opens up another can of worms.
Has anyone successfully solved a similar issue before and can provide guidance here?
This is a known limitation of the authentication methods for Community Connectors.
A workaround would be to use authtype NONE and then request the credentials and database information in the config. This is, however, not a recommended approach.
For a client, we have to connect a WSO2IS 5.10.0 to an Active Directory.
For that we have created a secondary user Store with this configuration:
User store main configuration
User store optional configuration
User store advanced configuration
WSO2IS can connect to Active Directory as we can retrieve users and roles.
Before doing any claim mapping we have tried to edit and create user without any problems.
And then we have mapped some claims to retrieve more information from Active Directory.
And here come our problems:
We can't create a user in Active Directory
We can't update a user in Active Directory
This two problem gives us this error :
Caused by: javax.naming.directory.NoSuchAttributeException: [LDAP: error code 16 - 00000057: LdapErr: DSID-0C090C45,
comment: Error in attribute conversion operation, data 0, v1db1
Things that we have tried:
Check (and check a second and third time) that all our claims are mapped correctly (and they are)
Reset all claims to default mapping (on the state where we where able to create/update user)
Set User DN Pattern (as explained here)
Restart on a fresh instance of WSO2IS 5.10.0
But all things that we have tried are not helping and we are stuck.
Any help would be hugely appreciated. Thank you for any suggestions.
As asked, this is the AD attribut we have mapped :
sn
givenName
cn
displayName
name
description
mail
sAMAccountName
userPrincipalName
accountExpires
pwdLastSet
userAccountControl
scriptPath
homePhone
mobile
facsimileTelephoneNumber
title
department
company
Here the issue is LDAP_NO_SUCH_ATTRIBUTE returned from the AD.
We don't know which attribute is missing on AD side.
From the existing DEBUG logs of the server, probably you wouldn't be able to log all the attributes that WSO2 is going to update. Therefore, you have to choose an alternative option.
Manual check - Even though there are only few attributes configured (and verified) by you, there are other claims with default attribute mappings. Please check all the mapped attributes that are there in the http://wso2.org/claim dialect.
Remote debug - Remote DEBUG the server to check what are the attributes WSO2 is trying to write in to. (Smaller subset than previous approach) Then verify if those exist.
To do this remote debugging you can check out the Kernel source code from here.
To find out the correct tag to checkout, you can find the kernel version of your identity server version from this release matrix.
Once you clone and checkout the correct tag, you can use IntelliJ Idea or a capable IDE to remote debug the server as explained in the this blog.
Though it's hard to point an exact line of code, you can put DEBUG points to ActiveDirectoryUserStoreManager.doAddUser() and ActiveDirectoryUserStoreManager.doSetUserClaimValue() methods and start from there.
P.S. You can also check if the carbon log's stack trace contains any clue of the failing attribute or the respective claim, so that you can check validate it.
I am trying to add the custom Attributes via the SQL, and I'm following the steps on [https://blogs.technet.microsoft.com/vinitt/2013/04/15/how-to-use-to-custom-sql-attribute-store-to-generate-claims-and-authorize-user]
I got the SQL Server setup, with the table 'attributes', but then I get to the step where it talks about the relaying party trust... Just edit the non-existent relaying party trust. (Application is working correctly right now, it is a website using ADFS to provide the Authentication, but not the authorization) - I had code for the API side to query the database and add Claims on the fly, but that only works for the server side code, we really need those claims in the JWT.
So, looking at this article everything looked great. I got the SQL Server, and I just need to add the rule to hit the server once the person's logon is validated.
Sounds like a piece of cake, but there is no where to add the claim rule - as I don't have (or need?) any relaying party trust - this can be handled 100% by the AD FS Server, so no need for any relaying. I tried to add one, but couldn't get past the first question. Guessed on that one, and couldn't get past the 2nd question. At this point I gave up... I doubt that entering random data into the form is going to work.
Can someone tell me how to add this? Please note: this is NOT a sharepoint site, and has nothing to do with Sharepoint. It is a .Net Site running an angular application that redirects to the ADFS Server and gets redirected back with the token..
So, anything wrong with this claim Rule:
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"]
=> issue(store = "SQL", types = ("http://schemas.microsoft.com/ws/2008/06/identity/claims/role"), query = "SELECT role from dbo.ADFS_attributes where logon={0}", param = c.Value);
Specifically, the attributes table has logon and role, and I'm trying to create roles based on records for that user. (In this case, it should create one per each result (I hope))
I've tried to change this to 'select 'Admin' role' in order to just always return a role to use, but that doesn't work either. I don't see any errors in the event log, just nothing... no change to the JWT that comes back.. (Still the same number of claims) - I can't even seem to add 'email' as a pass through claim, so I'm missing something here, or else, it is missing something here.. I don't know what.
OK, to make SURE this was working, I added the following claim rule:
=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/role", Value = "Admin");
Yep, added it right to the Active Directory Provider trust, so it would Always add the 'Admin' role. Nada.
I added it directly to the 'Web Application' / Issuance Transformation Rules, so there is no chance that it wouldn't be added.... Nope, nothing.
I also verified that the 'role' was in the claim description, and checked to publish as both accepted and sent...
Still getting the same old 10 items in the JTW that I always got..
Oh, and I tried restarting the 'Active Directory Federation Services' service...
And marked 'clear browser cache' when the debugger is up on the web page.
Sounds like ADFS just doesn't actually work, or none of the claims rules run. Is there a global setting somewhere that says 'enable custom rules' that needs to be turned on?
This is a better article since it doesn't reference SharePoint.
Also the rules should be "issue" rather than "add".
On the RP side, add the claims rules.
You need a RP trust because this is the application that is going to get the claims rules.
To add a RP trust manually, refer this.
Also, you mention JWT? What protocol are you using? SAML? OpenID Connect?
Turns out that you can add the rules to the 'Application Group' / "Web Application", and select the "Issuance Transform Rules" and add your SQL Claim rule there:
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"]
=> issue(store = "SQL", types = ("http://schemas.microsoft.com/ws/2008/06/identity/claims/role"), query = "SELECT role from dbo.ADFS_attributes where logon={0}", param = c.Value);
This allows you to add multiple roles if you have multiple roles.
The primary reason I wasn't seeing this was that the UI that was put on this was (somehow) posting a different token (without my roles) back to the API Server. I'm looking into where it got that token, why the token wasn't validated, (didn't come from the server, or it would have had my roles added)... Very strange,
Solved the issue by using PostMan to post to the server and then looked at the returned JWT that was good...
It seems that all JWT signing verification wasn't done by the last person...
I have an Azure Active Directory (AAD) set up in my Azure subscription associated with an email address of mine, which we'll call A.
Some time later, I updated my Microsoft Account to use a new email address B as the primary email address, with A being associated with it still so it can still be used and the two email addresses treated as being one.
In AAD there is one user, whose user Id is A which appears not to be able to be changed as it is greyed-out. Attempting to add B fails with the error: You cannot add yourself.
Is there a way I can force the user name of the AAD user to be B instead of A?
The reason I ask is because I am trying to setup an Azure Key Vault in my subscription as it appears to be failing because whether or not I sign in as A or B in Azure Powershell, I am always signed in as B. This then causes this error message, which I appear to be unable to work around:
New-AzureKeyVault : Cannot find the Active Directory object 'B' in tenant
'{Tenant Id}'. Please make sure that the user or application service principal you are
authorizing is registered in the current subscription's Azure Active directory. The TenantID displayed by the cmdlet
'get-AzureSubscription -current' is the current subscription's Azure Active directory.
Can you check that you are using the latest bits for Key Vault PowerShell?
I talked with some folks internally and we believe that an experience like this may be expected if you are using an older version of the PowerShell CMDLETs, but the lastest version should be update to date and not run into the issue you are having.
If you find that you still hit this issue after upgrading, we may have a bug on our side that we should fix.
In that case, my suggestion is for you to create a new Admin User. Then delete the old Admin Account (you may need to Transfer Onwership of your AAD Subscription to the new Admin), and then recreate your account, which will pull the lastest information from that user.
However, I only reccommend trying this after having updated the PowerShell bits.
Please let us know if either of these methods resolves your issues.
Thanks,
Shawn Tabrizi
I've set up LDAP authentication using pam_ldap on a server and it seemed to be working just fine to begin with, but now I have a problem. Whenever a user changes his password in Active directory, it syncs just fine with LDAP and therefor every system that uses LDAP authentication, except this server which still accepts the old password.
I've tried "getent passwd" and it does list every user in LDAP, and I also tried adding a new user in LDAP, which my server immediately recognized when I try "getent passwd" again.
So apparently my server is commmunicating with LDAP, just not when it comes to new passwords, those the server chooses to cache somewhere.
Google hasn't been helpful at all and some people seem to have had similar problems but their questions always go unanswered.
Hope someone can help.
You may have nscd installed. Check /etc/nscd.conf and lower the TTL.