-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
dn missing in attributes ? #60
Comments
How are you authenticating before this authproc runs? PS: I'm responding slowly due to a vacation and limited access to a computer. |
I'm using the authX509 module (which calls the ldap module internally) which seems to be working correctly - when I've verified that module using a different SP (that doesn't require an authproc) I get the expected attributes although no DN showing up there either. Also enjoy your vacation - this can wait until you return for sure. EDIT: This may be a problem in both the ldap and x509 modules. Doing a test from the SimpleSamlPHP console, I get all of the expected attributes except the 'dn' from the ldap module. When I test the authX509 module I get a very small number of attributes back (also missing the dn). I will be doing some more digging. |
With the fixes added for the authX509 module it now returns the same attribute list as the ldap module - but neither returns the “dn”. I can’t find any obvious reason for that but I’ll keep poking at the code. |
I suspect |
That's exactly how it is setup - that was what drove the patches I submitted for authX509 so it would respect the null attributes setting in the ldap module. I get all of the other attributes but the 'dn' is left out. |
So the fact that this is using Symfony and not straight PHP somehow escaped me. I was going by what the PHP documentation says which is: But Symfony doesn't do that, so you have to make another call to get the DN. In src/Auth/Source/Ldap.php, in function processAttributes, I did this:
And now I have the dn value I want. I can work on submitting an actual pull request but should this be the default behavior or an optional behavior ? And should it check first if 'dn' was even in the requested attributes before adding this ? |
I've got a simple authproc that calls ldap:AttributeAddUsersGroups to get the user's group information. Our LDAP is OpenLDAP that has groups with both groupOfNames and posixGroup objectclasses. So we have both uniqueMember and memberuid attributes our groups.
If I call that authproc like this - it works, the uid is used and matches the memberUid attribute:
However if I call it like this:
I get an error telling me 'dn' is not found in the attributes array. So, I added another authproc call to ldap:AttributeAddFromLDAP to go specifically grab 'dn' for the user. To my knowledge 'dn' is always returned by LDAP searches, but I figured let's try this:
Which itself works without error, but I still get the following on the very next call to 'ldap:AttributeAddUsersGroups' :
I can't find where or if 'dn' is somehow being filtered out but the attribute is definitely being returned by a search.
We'd like to switch to using the DN where we can but this has been a roadblock I can't figure out.
The text was updated successfully, but these errors were encountered: