On Thu, Jun 26, 2014 at 06:42:37PM -0400, Simo Sorce wrote: > On Thu, 2014-06-26 at 22:02 +0000, Nordgren, Bryce L -FS wrote: > > > The reason is that rpcidmapd` does not parse fully-qualified usernames > > > so"adt...@ad.example.org@IPA.EXAMPLE.ORG" does not work. > > > > If someone can educate me as to why there are two @ signs in the above, I > > can fix the wiki page > > (http://www.freeipa.org/page/Collaboration_with_Kerberos#Mechanism_1:_Kerberos_cross-realm_trusts) > > > > I know about individual cross-realm principals, > > > > adtest/ad.example....@ipa.example.org > > > > And I know about cross-realm trust principals: > > > > krbtgt/ad.example....@ipa.example.org > > > > But I was under the impression that if a user traversed a trust, their > > client principal name would still be adt...@ad.example.org . I am not aware > > of any circumstances which would produce a client principal with two "@" > > signs in it. Pls fix my ignorance. > > The second @ is not provided by kerberos, it is rpcimapd making false > assumptions, it does a getpwuid and gets back adt...@ad.example.org as > the username, to which it decides to slap on the local REALM name with > an @ sign in between. > > I think this is something that may be handled with imapd.conf > configuration. > > Simo.
Would the idmap sss module we have on the list pending review help here? -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
