AD Domain Trusts/LDAP Queries

[RickP]

Is it possible to build an LDAP based Resolver that will pull users thru the local DC from the remote Trust Domain?

I have tried to set:

BASE DN - DC=trusted,DC=com   (remote trusted domain)

Bind DN   - CN=svcaccout,OU=Service Accounts,DC=local,DC=com  (local trusting domain)  

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"

[Cornelius Kölbel]

Hi Rick,

can you try to not use the top level.
Use Base DN OU=some OU,dc=trusted,dc=com

Or check the box "no referreal chasing".

Tell, if this helps.

Kind regards
Cornelius

> --
> 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.
> To post to this group, send email to priva...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/privacyidea/3ed0b370-0ca7-426f-9cac-1effcc592536%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

--
Cornelius Kölbel
corneliu...@netknights.it
+49 151 2960 1417

NetKnights GmbH
http://www.netknights.it
Landgraf-Karl-Str. 19, 34131 Kassel, Germany
Tel: +49 561 3166797, Fax: +49 561 3166798

Amtsgericht Kassel, HRB 16405
Geschäftsführer: Cornelius Kölbel

[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.

[Cornelius Kölbel]

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:

# change this
LDAPURI = "ldap://yourserver"
LDAPBASE = "dc=tructed,dc=com"
BINDDN = "cn=user,dc=trusting,dc=com"
BINDPW = "password"

Thanks a lot
Cornelius

> --
> 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.
> To post to this group, send email to priva...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/privacyidea/887b3e42-a824-4ecf-bf41-8c49f51e388b%40googlegroups.com.

[RickP]

That script worked... well did not fail or report any error but did exactly as the query in the web tool, returns 0 results

./ldap-test.py

0 entries found.

[Cornelius Kölbel]

Are you running 2008R2 or 2012?

Kind regards
Cornelius

> --
> 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.
> To post to this group, send email to priva...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/privacyidea/a6e5e022-72d1-4af1-bed0-2383d21bffba%40googlegroups.com.

[Cornelius Kölbel]

Hi Rick,

I am interested in it, so I set up two domain controllers

domain1.trusting.com
domain2.trusted.com

both Windows 2012 and established a two way trust of type forst.

On a Linux machine I am running

ldapsearch -x -W -b "dc=trusted,dc=com" -D 'sv...@trusted.com' \
-H ldap://domain2.trusted.com '(objectClass=user)'

Which gives me the users all within the trusted.com domain.

Trying to use sv...@trusted.com user to get the users from the
trusting.com domain I get this:

ldapsearch -x -W -b "dc=trusting,dc=com" -D 'sv...@trusted.com' \
-H ldap://domain1.trusting.com '(objectClass=user)'

Enter LDAP Password:
ldap_bind: Invalid credentials (49)
additional info: 80090308: LdapErr: DSID-0C0903C5, comment:
AcceptSecurityContext error, data 52e, v2580

So either I have not established the trust correct or I am failing with
the openldap tools.

Can you point out, what you did so far, what fails and what you expect?

Thanks a lot
Cornelius

[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 

Our config is a one way trust similar to this https://i-technet.sec.s-msft.com/dynimg/IC195286.gif

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

[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 admini...@trusted.com
and browse the users.

Now I am doing the following:

root@privacyidea:~# ldapsearch -vvvvv -x -W -b \
"cn=users,dc=trusting,dc=com" -D \
'cn=administrator,cn=users,dc=trusted,dc=com' -H \
ldap://domain2.trusted.com '(objectClass=user)'


ldap_initialize( ldap://domain2.trusted.com:389/??base )
Enter LDAP Password:
filter: (objectClass=user)
requesting: All userApplication attributes
# extended LDIF
#
# LDAPv3
# base <cn=users,dc=trusting,dc=com> with scope subtree
# filter: (objectClass=user)
# requesting: ALL
#

# search result
search: 2
result: 10 Referral
text: 0000202B: RefErr: DSID-0310082F, data 0, 1 access points
ref 1: 'trust
ing.com'

ref: ldap://trusting.com/cn=users,dc=trusting,dc=com

# numResponses: 1

In this case I connect as admini...@trusted.com to the DC in
trusted.com and request the users in dc=trusting,dc=com.

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

> --
> 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.
> To post to this group, send email to priva...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/privacyidea/9b54d853-d64c-4688-bf82-45dd103c5aee%40googlegroups.com.

[Cornelius Kölbel]

Hi Rick,

I did some research with the underlying python module:
https://github.com/cannatag/ldap3/issues/120

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
1. 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.
2. 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
Cornelius

[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

[Cornelius Kölbel]

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
Cornelius

> --
> 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.
> To post to this group, send email to priva...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/privacyidea/c4765a6e-940f-4fc1-b1eb-b3ddbb476b8a%40googlegroups.com.

[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

[Cornelius Kölbel]

So speaking of API level:

You are getting a request

POST /validate/check

user=trusteDomain\\username
pass=secret123456

Is this comming from RADIUS?

Ok. Look out. There is a realm wired policy:
http://privacyidea.readthedocs.org/en/latest/policies/authentication.html#mangle

"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
Cornelius

> --
> 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.
> To post to this group, send email to priva...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/privacyidea/bc0e63fd-28a9-447e-b06d-7018d988aafd%40googlegroups.com.

[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

[Cornelius Kölbel]

Hi Rick,

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
Cornelius

> --
> 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.
> To post to this group, send email to priva...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/privacyidea/c975fc6b-285c-4ef9-86c5-f945f805f3d1%40googlegroups.com.

[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!!

[Cornelius Kölbel]

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

> --
> 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.
> To post to this group, send email to priva...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/privacyidea/1d6d06c1-6991-4c81-bee1-a7861280be90%40googlegroups.com.

[James McCracken]

Hi Cornelius,

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:

 //etc/privacyidea/logging.cfg
[formatters]
keys=detail

[handlers]
keys=file

[formatter_detail]
class=privacyidea.lib.log.SecureFormatter
format=[%(asctime)s][%(process)d][%(thread)d][%(levelname)s][%(name)s:%(lineno)d] %(message)s


[handler_file]
# Rollover the logfile at midnight
class=logging.handlers.RotatingFileHandler
backupCount=14
maxBytes=10000000
formatter=detail
level=DEBUG
args=('/var/log/privacyidea/privacyidea.log',)

[loggers]
keys=root,privacyidea

[logger_privacyidea]
handlers=file
qualname=privacyidea
level=DEBUG

[logger_root]
level=NOTSET
handlers=file

[Cornelius Kölbel]

Hi Jim, Hi Rick,

The mangle action is ok. (Without mangle=)

Do you have any further settings in the policy, which might result in not triggering the policy?

Like realms, clientIP...

Is the policy active (sorry :-)

If you like to, I can send you some code modifications with more debug output.

Kind regards

Cornelius

Cornelius Kölbel

Corneliu...@netknights.it

+49 151 2960 1417

NetKnights GmbH

http://netknights.it

Landgraf-Karl-Str. 19, 34131 Kassel, Germany

Tel: +49 561 3166797, Fax: +49 561 3166798

Amtsgericht Kassel, HRB 16405

Geschäftsführer: Cornelius Kölbel

-------- Ursprüngliche Nachricht --------
Von: James McCracken <merl...@gmail.com>
Datum: 04.11.2015 17:39 (GMT+01:00)
An: privacyidea <priva...@googlegroups.com>
Betreff: Re: AD Domain Trusts/LDAP Queries

To view this discussion on the web visit https://groups.google.com/d/msgid/privacyidea/2e85f5fc-4dfe-42a7-af56-a6187c959e36%40googlegroups.com.

[RickP]

Yes Active Check is on
Scope is "authentication"
Action is { "mangle": "user/.*(.{4})/\1/" } 
Realm/User/Resolver/Client are all None Selected or Empty

[James McCracken]

FYI, this is an SSH authentication... does the mangle authentication policy work in that case?

[Cornelius Kölbel]

Hi Jim,

it should not matter.

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
Cornelius

> --
> 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.
> To post to this group, send email to priva...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/privacyidea/ef8e8f5e-49b0-4c30-9bfb-56d5b0520a9a%40googlegroups.com.

[RickP]

we dropped this new file prepolicy.py into place and restarted the web services, but still are not seeing anything in the log file relating to mangle, mangling, mangler

[RickP]

Knowing now what "prepolicy" file was supposed to be ran, we sprinkled log.debug msgs all thru that file, and it never writes anything to the log.

Are we sure the mangle policy is ran with SSH key validation and not just with the OTP components?

[Cornelius Kölbel]

Touché!

I misunderstood your setup.
I thought that you are using SSH with online authentication (OTP)
against privacyIDEA.

But indeed: The ssh KEY authentication works a bit different.

Are you using AuthorizedKeysCommand to retrieve the users keys in real
time from privacyIDEA?
...with the script privacyidea-authorizedkeys from the admin client?

https://github.com/privacyidea/privacyideaadm/blob/master/scripts/privacyidea-authorizedkeys

Kind regards
Cornelius

> --
> 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.
> To post to this group, send email to priva...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/privacyidea/9974f1f7-2a36-4248-b909-40f60358ed65%40googlegroups.com.

[Cornelius Kölbel]

Hi Rick,

I added an issue
https://github.com/privacyidea/privacyidea/issues/256

(I also already have the fix, which was one line of import and one line
of code ;-)

Well, but I think you might not have the ssh keys quite right:

The token type SSH key is assigned to a user.

But this user it is assigned to, is not necessarily the local user on
the ssh server.

e.g.

Image a domain administrator "rickp", who has his personal ssh key token
"sshtoken1" assigned.
But this user want to login with this ssh key to a ssh server
"sshserver1" as user "root".

This is why you can add an option to the machinetoken assignment:

"sshserver1" <---[App: ssh]--- "sshtoken1"
options: user=root

I very much like to discuss you scenario to get the ssh token
functionality improved.

I assume your ssh users are always the same username, like in
privacyIDEA, i.e.

ssh user on ssh server: DOMAIN\\rickp
token owner in privacyidea: rickp

Kind regards
Cornelius

[RickP]

Exactly what we are doing, pulling ssh keys via 

AuthorizedKeysCommand /usr/bin/privacyidea-authorizedkeys

[Cornelius Kölbel]

I created a branch with a tiny patch in privacyidea-authorizedkeys.
At the moment this seems to be simpler, than pushing the changes in the
server.

https://github.com/privacyidea/privacyideaadm/commit/8c1d464be7ed03941c21fbada82f6c72aa62d2c8

But you need to set the "user" option for the ssh machine assignment.

Kind regards
Cornelius

Am Donnerstag, den 05.11.2015, 09:54 -0800 schrieb RickP:
> Exactly what we are doing, pulling ssh keys via
>
>
> AuthorizedKeysCommand /usr/bin/privacyidea-authorizedkeys
>
>
>

> --
> 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.
> To post to this group, send email to priva...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/privacyidea/865878a5-6d9b-492e-8454-05550e10b77a%40googlegroups.com.

[Cornelius Kölbel]

Hi Rick,

I think that you changed your directory structure, so you do not need
domain trust anymore.
Nevertheless there was a movement in the trusted domain topic.

https://github.com/cannatag/ldap3/issues/120

So changes are good, that domain trust will work with the unterlying
LDAP library.
...just to let you know.

Kind regards
Cornelius

Am Donnerstag, den 05.11.2015, 09:54 -0800 schrieb RickP:

> Exactly what we are doing, pulling ssh keys via
>
>
> AuthorizedKeysCommand /usr/bin/privacyidea-authorizedkeys
>
>
>

> --
> 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.
> To post to this group, send email to priva...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/privacyidea/865878a5-6d9b-492e-8454-05550e10b77a%40googlegroups.com.