I am pulling information from our Active Directory... however i am wanting to see which groups are internal or external.
So far on googling it seems that the
RequireSenderAuthenticationEnabled
is the switch to say if it external or extgernal.
What table and field in Active Directory is that information held.
Thanks
Chris
It's the msExchRequireAuthToSendTo attribute.
That attribute defines whether Exchange will reject emails from unauthenticated users.
"Unauthenticated" usually means "coming from outside your network", but not always. If an email is sent from inside your network via SMTP without authentication, it would still be rejected if that attribute is set to TRUE.
Related
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've an Azure AD B2C setup that no matter which email I insert in forgot password email's field it will send the verification code email to that email.
Even if the email doesn't exists in the Users list.
Is this the default behavior?
This is the link I have for recover password
Is there any missing property in the url that force check if the email exists in User list ?
I can confirm the behavior but I couldn't find any reference on why exactly it works that way. Like many things in security, I'm pretty sure it's a design trade-off.
Some services (e.g. Evernote) do the same, i.e. they send a password reset email no matter if the address is registered with them or not.
On the upside, this is an early alert for the user that someone is trying to get access their (nonexistent) account, so a phishing attempt coming from a different website is likely.
The problem is that the user gets an unsolicited email message, and if somebody wants to annoy him/her, all it has to do is to send multiple reset password requests. The user is helpless, there's nothing he can do to stop the emails. So I presume the service mitigates this by limiting the number of reset password requests to a reasonable amount (say max 10/hour, but no more than 3 in any 5 minutes).
Other services (e.g. Dropbox) take the other approach and only send email messages to addresses registered with their service.
this prevents the "email bomb" issue
on the other hand, it doesn't alert the user about the login attempt
Like you, I would argue that the latter approach is better, as the only benefit I can see in the former one is the "early warning" issued to a user that's not even registered with your service. Also, understanding the early warning requires some user sophistication. But obviously Microsoft went the other way.
There's a Password Reset item in the Users blade, but the only options are None and All. Interestingly, the tooltip on this option mentions an nonexistent "Selected" option, so some more fine-grained settings may appear here in the future.
If you want to exists if the users exist before sending messages then you have to edit the SendCode Action . So it will only send verification code when user exists in B2C side.
Below is the very good link which can help you with that.
https://github.com/azure-ad-b2c/samples/tree/master/policies/pwd-reset-email-exists
It is by design. And it will try to send out the verification code without validating whether email exists or not.
By considering security measures this is how it should work.
Is it possible to set a custom value for the service that active directory is providing?
I am having hard time figuring this out as all the research I did on microsoft, oracle, and MIT websites yielded nothing.
Any help is appreciated.
It seems your Kerberos is tied to an Active Directory.
Consider adding a custom attribute in Active Directory instead, for example,
https://social.technet.microsoft.com/wiki/contents/articles/20319.how-to-create-a-custom-attribute-in-active-directory.aspx
You could get principal name from a Kerberos ticket, then make request to AD to get that custom attribute for that principal. (assuming your custom attributes could be at a principal level)
I don't think you could create custom attributes for the ticket itself.
I'm trying to work out why some of our users aren't issued claims by our custom attribute stores.
Our main attribute store for authentication is Active Directory, but we are using two custom attribute stores to issue several custom claims to users, and also to perform some logging of claims issued. When an affected user logs in, they are authenticated successfully by AD, but have no more claims added. According to the logging in our attribute stores, the BeginExecuteQuery is never called.
I can't see anything to link the affected users, but they mainly seem to be new users, or users that have not logged into the system in a long time. Restarting ADFS sometimes clears the problem, but whether it does or not seems to be random.
I'm trying to understand why an attribute store would be ignored by ADFS on logon for certain users, when it works fine for others. If there is a quick guaranteed temporary fix to get users' claims issued correctly, that would be useful too!
For security reasons, I don't have access to the ADFS Debug tracing.
This was eventually solved with a longs string of calls to Microsoft's AD FS support team. The problem was traced to a piece of our claims rule language which was using the lastLogon and lastLogonTimestamp AD attributes without understanding how they actually behaved. This meant that for some users the condition to grant the custom claims was never met.
I have an application that uses email addresses for user authentication.
I know that some universities use Shibboleth for user authentication, and I was wondering what the process is for being able to read emails from the university database that is used for Shibboleth. Note that I do not care about authentication through Shibboleth, I only need to be able to read the email addresses.
Is it general for all universities that use Shibboleth, or is each a unique case?
Any links to documentation on how to do this process would be greatly appreciated. Thank you.
Shibboleth can be configured (IdP-side) to release user attributes along with authentication data, for example the user's email address. Client-side, assuming you're going though shibd, you'll need a setting in your attribute-map.xml that says "map attribute with OID x.y.z.a to environment variable USERMAIL" and then you get the result in that environment variable. The example config should already contain it.
This would be the same for everybody insofar as the OID for "email" is always the same, but you'd have to negotiate with the IdPs (universities) or their federations so that they will actually release that attribute to you.
Shibboleth is used by many institutions, but by no means all. Many use Athens, proxies or IP recognition, among other things.
As far as I am aware, a user's email address is not tied directly to the Shib system. When a user tries to access a Shibboleth-protected resource they are taken to their institution's login page to authenticate themselves. They might enter their email address to authenticate or they might enter a username, they might be auto logged-in based on their IP address, or something else.
The institution does send back an affiliation through Shib data transfer upon successful login, something like student#brown.ac.uk but this is not necessarily the email address the user used to login. I guess they could send that but it has not been used in system's I've worked on.
Shibboleth is commonly used to check that the user is from an institution that has purchased access to a protected resource rather than identifying a particular user from that institution so the user's email isn't needed.
Not sure if this helps at all: http://middleware.internet2.edu/eduperson/docs/internet2-mace-dir-eduperson-200806.html#eduPersonAffiliation