AD Domain Trusts/LDAP Queries

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”

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
CorneliusAm Montag, den 26.10.2015, 14:06 -0700 schrieb 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”

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+unsubscribe@googlegroups.com.
To post to this group, send email to privacyidea@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
@cornelinux
+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

signature.asc (836 Bytes)

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.

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.

Are you running 2008R2 or 2012?

Kind regards
CorneliusAm Dienstag, den 27.10.2015, 12:51 -0700 schrieb 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.


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+unsubscribe@googlegroups.com.
To post to this group, send email to privacyidea@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/privacyidea/a6e5e022-72d1-4af1-bed0-2383d21bffba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Cornelius Kölbel
@cornelinux
+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

signature.asc (836 Bytes)

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

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+unsubscribe@googlegroups.com.
To post to this group, send email to privacyidea@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/privacyidea/887b3e42-a824-4ecf-bf41-8c49f51e388b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Cornelius Kölbel
@cornelinux
+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

ldap-test.py (902 Bytes)

signature.asc (836 Bytes)

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 ‘svcpi@trusted.com’
-H ldap://domain2.trusted.com ‘(objectClass=user)’

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

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

ldapsearch -x -W -b “dc=trusting,dc=com” -D ‘svcpi@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
CorneliusAm Dienstag, den 27.10.2015, 21:14 +0100 schrieb Cornelius Kölbel:

Are you running 2008R2 or 2012?

Kind regards
Cornelius

Am Dienstag, den 27.10.2015, 12:51 -0700 schrieb 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.


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+unsubscribe@googlegroups.com.
To post to this group, send email to privacyidea@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/privacyidea/a6e5e022-72d1-4af1-bed0-2383d21bffba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Cornelius Kölbel
@cornelinux
+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


Cornelius Kölbel
@cornelinux
+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

signature.asc (836 Bytes)

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.

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 administrator@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

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

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


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+unsubscribe@googlegroups.com.
To post to this group, send email to privacyidea@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/privacyidea/9b54d853-d64c-4688-bf82-45dd103c5aee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Cornelius Kölbel
@cornelinux
+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

signature.asc (836 Bytes)

Hi Rick,

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

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

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 administrator@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

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

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


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+unsubscribe@googlegroups.com.
To post to this group, send email to privacyidea@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/privacyidea/9b54d853-d64c-4688-bf82-45dd103c5aee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Cornelius Kölbel
@cornelinux
+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


Cornelius Kölbel
@cornelinux
+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

signature.asc (836 Bytes)

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

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

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 :wink:
    (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


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+unsubscribe@googlegroups.com.
To post to this group, send email to privacyidea@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/privacyidea/bc0e63fd-28a9-447e-b06d-7018d988aafd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Cornelius Kölbel
@cornelinux
+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

signature.asc (836 Bytes)

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


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+unsubscribe@googlegroups.com.
To post to this group, send email to privacyidea@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/privacyidea/c4765a6e-940f-4fc1-b1eb-b3ddbb476b8a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Cornelius Kölbel
@cornelinux
+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

signature.asc (836 Bytes)

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

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


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+unsubscribe@googlegroups.com.
To post to this group, send email to privacyidea@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/privacyidea/ef8e8f5e-49b0-4c30-9bfb-56d5b0520a9a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Cornelius Kölbel
@cornelinux
+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

prepolicy.py (26 KB)

signature.asc (836 Bytes)

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=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

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

For more options, visit https://groups.google.com/d/optout.


Cornelius Kölbel
corneliu...@netknights.it <javascript:>
+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

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


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+unsubscribe@googlegroups.com.
To post to this group, send email to privacyidea@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/privacyidea/c975fc6b-285c-4ef9-86c5-f945f805f3d1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Cornelius Kölbel
@cornelinux
+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

signature.asc (836 Bytes)

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

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