I get a valid test indicated the LDAP query and account information was
processed but get 0 results.
“Your LDAP config seems to be OK, 0 user objects found”
I get a valid test indicated the LDAP query and account information
was processed but get 0 results.
“Your LDAP config seems to be OK, 0 user objects found”
BASE DN - OU=Personal Accounts,DC=trusted,DC=com (remote trusted domain)
With or without the No anonymous referral chasing, the return is:
“Your LDAP config seems OK, 0 User objects found”
On linux systems joined to the local trusting domain with Power Broker or
SSSD/Realm joining them to the domain we are able to lookup users from the
remote trusted domain.
I take it that you know what you are doing and you configured the
mapping attributes right.
I do not know of any that kind of setup and probably we will have to
take a look ant the underlying ldap3 python module.
The code at the interesting code passage does not contain any usuable
debug output.
So I would like to try to see what the underlying python module does.
I attached a small script, which you can run with
python ldap-test.py
Please adapt the config at the beginning of the script:
Thanks a lot
CorneliusAm Dienstag, den 27.10.2015, 05:34 -0700 schrieb RickP:
Thanks for the quick reply.
Tried a more specific targeted OU
BASE DN - OU=Personal Accounts,DC=trusted,DC=com (remote trusted
domain)
With or without the No anonymous referral chasing, the return is:
“Your LDAP config seems OK, 0 User objects found”
On linux systems joined to the local trusting domain with Power Broker
or SSSD/Realm joining them to the domain we are able to lookup users
from the remote trusted domain.
I setup my two domain controllers 2012R2 with a one way trust.
I was able to connect to trusting.com with my administrator@trusted.com
and browse the users.
Yeah, I get a referral but to my knowledge openldap could chaise
referrals only anonymously. Which will of course fail.
And which is the reason why privacyIDEA has a checkbox “Do not chase
referrals anonymously”.
I configured a resolver and can reproduce your problem (see screenshot
in german)
I also get the same result when using NTLM and TRUSTED.COM
\Administrator.
Having this starting point I will see if there are any possibilities
with the underlying ldap3 python module.
I this does not help…
Maybe you can setup a meta directory that combines trusted and
trusting…?
Kind regards
Cornelius
Am Donnerstag, den 29.10.2015, 08:00 -0700 schrieb RickP:
Our domains are on 2012 R2
The second search you are doing in your example would not be able to
reach across the for authentication, least not in our environment. we
need the local “Trusting” domain DCs to do the referrals to reach
across to the Trusted DCs to pull the users
With linux realmd/sssd we can join machines to the “trusting” domain
then use the linux id command to pull info for the users that are in
the trusted domain, havent figured out the ldap query method to
accomplish this yet
Our query works, well doesnt fail from any password or access reported
issue, but returns no results using:
Server URI: ldaps://corp-cli-dc1.client.ext
BASE DN: OU=Personal Accounts,DC=trusted,DC=com
Bind DN: CN=svcacct,OU=Service Accounts Exception,OU=Support
Resources,DC=trusting,DC=ext
I did some research with the underlying python module:
My understanding so far is the following:
The ldap3 module can follow referrals and will contact the trusting.com
domain controller.
But this will fail when doing a simple bind or NTLM or even SASL
DIGEST-MD5.
Doing a wireshark on the Windows DC/DC I saw that they are doing SASL
GSSAPI.
Well - and somehow this makes sense.
So I guess that
privacyIDEA, the LDAP searching system needs to be member of the
kerberos trusted domain. Otherwise the trusting domain would not trust a
request issued from a machine, not in the trusted domain.
the LDAP search via referral on the trusting domain needs to be
performed with a Kerberos ticket.
This means that we need to put privacyIDEA into the trusted domain and
slightly modify the code to use SASL GSSAPI.
We could however try to use the univention corporate server, which
should be easily joined into the trusted domain and which also can run
privacyIDEA.
Still, we need to deal with some obstacles. Required python packages
(python-gssapi) are not available for Debian/Ubuntu…
So this is some kind of research/development task, which requires a bit
more effort.
As a matter of fact my company NetKnights provides services and support
for privacyIDEA. If you are interested in following this path, we can
take this off-list.
In the end it would be great to also add support for Kerberos/GSSAPI and
trusted domains to privacyIDEA.
Kind regards
CorneliusAm Donnerstag, den 29.10.2015, 18:16 +0100 schrieb Cornelius Kölbel:
Hi Rick,
I setup my two domain controllers 2012R2 with a one way trust.
I was able to connect to trusting.com with my administrator@trusted.com
and browse the users.
Yeah, I get a referral but to my knowledge openldap could chaise
referrals only anonymously. Which will of course fail.
And which is the reason why privacyIDEA has a checkbox “Do not chase
referrals anonymously”.
I configured a resolver and can reproduce your problem (see screenshot
in german)
I also get the same result when using NTLM and TRUSTED.COM
\Administrator.
Having this starting point I will see if there are any possibilities
with the underlying ldap3 python module.
I this does not help…
Maybe you can setup a meta directory that combines trusted and
trusting…?
Kind regards
Cornelius
Am Donnerstag, den 29.10.2015, 08:00 -0700 schrieb RickP:
Our domains are on 2012 R2
The second search you are doing in your example would not be able to
reach across the for authentication, least not in our environment. we
need the local “Trusting” domain DCs to do the referrals to reach
across to the Trusted DCs to pull the users
With linux realmd/sssd we can join machines to the “trusting” domain
then use the linux id command to pull info for the users that are in
the trusted domain, havent figured out the ldap query method to
accomplish this yet
Our query works, well doesnt fail from any password or access reported
issue, but returns no results using:
Server URI: ldaps://corp-cli-dc1.client.ext
BASE DN: OU=Personal Accounts,DC=trusted,DC=com
Bind DN: CN=svcacct,OU=Service Accounts Exception,OU=Support
Resources,DC=trusting,DC=ext
The second search you are doing in your example would not be able to reach
across the for authentication, least not in our environment. we need the
local “Trusting” domain DCs to do the referrals to reach across to the
Trusted DCs to pull the users
With linux realmd/sssd we can join machines to the “trusting” domain then
use the linux id command to pull info for the users that are in the trusted
domain, havent figured out the ldap query method to accomplish this yet
Our query works, well doesnt fail from any password or access reported
issue, but returns no results using:
Server URI: ldaps://corp-cli-dc1.client.ext
BASE DN: OU=Personal Accounts,DC=trusted,DC=com
Bind DN: CN=svcacct,OU=Service Accounts Exception,OU=Support
Resources,DC=trusting,DC=ext
would these policies be a way to strip domain info from the incoming
requests?
the issue I am fighting with now is that the privacyidea-authorizedkeys is
picking up the full domain user id as trustedDomain\myuserid but the
privacyIdea side knows not that user even though he is being pulled
directly from the AD on the trustedDomain side, the user privacyIdea knows
is just myuserid
“Mangle”. You can use this to modify the incoming authentication request
and yes, you can modify the username. You could even modify the password
if you are not content with the password, the user sent
(We did not have that much beer to come up with the idea)
So in your case, stripping the leading domain name would be something
like
mangle=user/trustedDomain\\\\(.*)/\\1/
Just stripping the whole trustedDomain stuff and the backslashes.
But I would recommend taking a look at RADIUS, to avoid the domain name
in the first place.
Kind regards
CorneliusAm Freitag, den 30.10.2015, 12:16 -0700 schrieb RickP:
would these policies be a way to strip domain info from the incoming
requests?
the issue I am fighting with now is that the
privacyidea-authorizedkeys is picking up the full domain user id as
trustedDomain\myuserid but the privacyIdea side knows not that user
even though he is being pulled directly from the AD on the
trustedDomain side, the user privacyIdea knows is just myuserid
We have decided to just allow port 443 from the trusting domain/network
reach into the Trusted domain and build all our privacyIdea architecture
inside the Trusted Domain, so far testing seems to work in that layout,
avoiding the domain referrals all together
Sometimes the simpler way might be more robust and reliable.
Please note, that you can define policies http://privacyidea.readthedocs.org/en/latest/policies/index.html
to adapt the behaviour of privacyIDEA during authentication and
management.
This can also be done client dependent - i.e. requests issued from
different client IP address can be handled differently.
Thus you could allow management only from within trusted or vice versa.
Kind regards
CorneliusAm Freitag, den 30.10.2015, 11:14 -0700 schrieb RickP:
We have decided to just allow port 443 from the trusting
domain/network reach into the Trusted domain and build all our
privacyIdea architecture inside the Trusted Domain, so far testing
seems to work in that layout, avoiding the domain referrals all
together
No the domain/username isn’t coming Radius, its coming from a linux host
joined to an AD domain where users log in with “default” domain prefixed so
it finds their userIDs in a trusted AD domain forest.
All users exist in one specific AD domain and are trusted into other
domains. the prefixed DOMAIN\username will always be the same Domain…
well least for now
We could create the keys/user/computer associations to include the DOMAIN\
prefix but would prefer I think to just strip it off from the client
request side or at the server “mangle” user step
Basically it would help to run a tail -f on the privacyidea.log when the
authentication happens.
Also if we do not see the mangle log entry, we may see other entries,
which give us an idea of how the user object looks like and what happens
around the mangling.
Nevertheless I attached a file prepolicy.py which can replace the file
privacyidea/api/lib/prepolicy.py based on version 2.7.
Can you please replace this file, restart the webserver, running with
loglevel DEBUG and send the corresponding log file.
Thanks a lot and kind regards
CorneliusAm Mittwoch, den 04.11.2015, 10:26 -0800 schrieb James McCracken:
FYI, this is an SSH authentication… does the mangle authentication
policy work in that case?
On Wednesday, November 4, 2015 at 1:13:39 PM UTC-5, RickP wrote:
Yes Active Check is on
Scope is “authentication”
Action is { “mangle”: “user/.*(.{4})/\1/” }
Realm/User/Resolver/Client are all None Selected or Empty
I work with Rick. We’ve been running with loglevel DEBUG all morning and a
mangle field of { “mangle”: “user/.*(.{4})/\1/” }, yet when I run: “cat
/var/log/privacyidea/privacyidea.log | grep mangling”, I get no result. I
also tried mangle=… as the mangle field but that resulted in { “mangle”:
“mangle”} so didn’t seem right.
Here is our logging config in case we got something wrong there:
[logger_root]
level=NOTSET
handlers=fileOn Wednesday, November 4, 2015 at 9:05:04 AM UTC-5, Cornelinux K wrote:
Hi Rick,
you should be able to see a log entry in loglevel DEBUG in
privacyidea.log like:
"mangling authentication data: %s"
So set loglevel to DEBUG and restart the webserver.
How does your policy look like?
Kind regards
Cornelius
Am Mittwoch, den 04.11.2015, 05:54 -0800 schrieb RickP:
Yes we have been working with the mangle policy this morning but with
no success so far, is there a way to debug the mangle policy to see
what is being parsed out and presented as the final user lookup?
Thanks!!
–
You received this message because you are subscribed to the Google
Groups “privacyidea” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to privacyidea...@googlegroups.com <javascript:>.
To post to this group, send email to priva...@googlegroups.com
<javascript:>.
To view this discussion on the web visit
ok, the authentication request contains “domain/username” and the
resolver/realm in privacyIDEA only contains the “username”.
This is fine.
Did you try the mangle policy?
This should solve this issue.
Kind regards
CorneliusAm Dienstag, den 03.11.2015, 13:05 -0800 schrieb RickP:
No the domain/username isn’t coming Radius, its coming from a linux
host joined to an AD domain where users log in with “default” domain
prefixed so it finds their userIDs in a trusted AD domain forest.
All users exist in one specific AD domain and are trusted into other
domains. the prefixed DOMAIN\username will always be the same
Domain… well least for now
We could create the keys/user/computer associations to include the
DOMAIN\ prefix but would prefer I think to just strip it off from the
client request side or at the server “mangle” user step
FYI, this is an SSH authentication… does the mangle authentication policy
work in that case?On Wednesday, November 4, 2015 at 1:13:39 PM UTC-5, RickP wrote:
Yes Active Check is on
Scope is “authentication”
Action is { “mangle”: “user/.*(.{4})/\1/” }
Realm/User/Resolver/Client are all None Selected or Empty