Re: [Freeipa-users] Library to change expired password

[Sumit Bose]

On Thu, Oct 29, 2009 at 10:54:01PM -0600, Jason Gerard DeRose wrote:
> On Thu, 2009-10-29 at 17:56 -0400, Dan Scott wrote:
> > Hi,
> > 
> > I'm trying to integrate FreeIPA with a Java webapp using JAAS. I have
> > the login module configured properly and it is working fine.
> > 
> > However, I have a problem with the initial user setup. New accounts
> > are created with expired passwords for good reason. However, I would
> > like a way to for a user to change their expired kerberos password
> > which does not use the command line. e.g. an SSL web form.
> > 
> > On searching the web, there does not appear to be a (free) java
> > library which implements the same functionality as ipa-passwd, kinit
> > or ssh for changing expired passwords. Does anyone know if such a
> > thing exists? The IPA documentation indicates that ssh has an option
> > 'challenge-response' for changing expired passwords. I would like the
> > same functionality on a web page.
> 
> Yes, you raise a good point and we obviously need a way to do this via
> the web UI.
> 
> Rob, if a user's password is expired, how does the password change work?
> Does the user still do a Kerberos auth with the old password, or do we
> need a non-Kerberos protected web page through which to update the
> password?
> 
> Either way, this will be a simple thing to add to the UI.
> 

If the password is expired you get KRB5KDC_ERR_KEY_EXP when requesting a
TGT. Please note that you will always get this response not matter if
the password matches the old password or not. You can then request a
password change ticket, principle: kadmin/changepw, with tho old
password and run the password change with this ticket.

I would expect that you cannot use a kerberos protected page, because
you do not have a TGT and cannot request a service ticket for the web
server.

bye,
Sumit

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Question about the FreeIPA 2.x alpha

[Sumit Bose]

On Thu, Nov 12, 2009 at 10:36:06AM +0100, Jakub Hrozek wrote:
> On 11/11/2009 11:53 PM, Stephen P. Sandifer wrote:
> > Has anyone successfully built the alpha package from source?
> > 
> > I thought I'd solved all the dependencies but it does not seem to build
> > successfully. For those who did, would you mind letting me know what
> > your Linux distribution is?
> > 
> > Thank you,
> > Stephen Sandifer
> 
> Stephen,
> what is the particular error you are seeing? I did rebuild the alpha
> release for demo purposes last week on Fedora 11.
> 
> I think I had to manually rebuild and install the wehjit and assets
> packages (WebUI infrastructure packages) as they are not available for F11.
> 
>   Jakub
> 

The fc13 packages from koji:

http://kojipkgs.fedoraproject.org/packages/python-assets/0.1.1/2.fc13/noarch/python-assets-0.1.1-2.fc13.noarch.rpm
http://kojipkgs.fedoraproject.org/packages/python-wehjit/0.1.1/2.fc13/noarch/python-wehjit-0.1.1-2.fc13.noarch.rpm

are working for me on F11, too.

bye,
Sumit

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Is sssd currently useable with freeipa v2 ?

[Sumit Bose]

On Sun, May 02, 2010 at 08:41:14PM +0200, Oliver Burtchen wrote:
> Am Sonntag, 2. Mai 2010 04:43:22 schrieb Rob Crittenden:
> > Oliver Burtchen wrote:
> > > Hi Stephen,
> > >
> > > I nailed the problem now a little bit down. I think it's HBAC with it's
> > > empty rules in the standard configuration. For me it was hard to
> > > recognize that it prevents every user added with "ipa user-add" from
> > > logging in the server or joined machines (via ssh or console). When I do
> > > a "ipa-client-install --on- master --permit" everthing works fine.
> > > Without the "--permit" I always get a access denied via
> > > pam-configuration.
> > >
> > > Are there any documentations ready for reading/review for HBAC with
> > > freeipa? At least it would be nice to have some short docu what is
> > > necessary. Could you lead me a little bit?
> > 
> > You need at least sssd 1.1.1 for hbac to work. I just added a tiny bit
> > of documentation on this yesterday at
> > http://freeipa.org/page/CLI_Overview#hbac
> > 
> > It might point you in the right direction anyway. I hope to have more
> > thorough documentation on it available soon.
> 
> Thanks for the hint. Just for the record, here are some more Informations:
> http://freeipa.org/page/Concepts_and_Objects#Host_Based_Access_Control

Even more information can be found here:
http://freeipa.org/page/DS_Design_Summary#HBAC_object
This page is basically what I used to implement the IPA HBAC rules in
sssd.

> 
> > 
> > The default configuration in hbac uses the model "denied unless
> > explicitly allowed" which is why all your logins failed. We don't
> > currently have any default rules set up, I wonder if we should have some
> > basic ones for demonstration purposes and to sort of bootstrap things.
> 
> Well, I played around a little bit and managed to setup rules to allow ssh-
> login. Now I have some more questions:
> 
> a) Is it right that I cannot use wildcards or placeholders in the service-
> name? I tried "all" and "*", but only explicite naming like "ssh" or "sshd" 
> works.

If the service is empty every service is allowed.


> 
> b) Is it right, that I have to set host and source-host? For me, it doesn't 
> work if I do not. My first thought was, if it's not set, it should always 
> match. 

Please set the source host category to 'all':
 ipa hbac-mod --srchostcat=all YOUR_RULE_NAME

> 
> c) Like a), how to set up a rule for all hosts or source-hosts? Do I have to 
> put them all in a hostgroup? If so, than it would be very handy, if ipa could 
> manage such group automagically for reference.

There is also a host category and a user category to set:
 ipa hbac-mod --hostcat=all YOUR_RULE_NAME
 ipa hbac-mod --usercat=all YOUR_RULE_NAME

> 
> d) How to setup a rule which restrics services like nfs to the lan (and known 
> hosts), but permits ssh from every machine over the internet (unknown hosts)?

You will need two rules one for the service sshd and one for nfs.

> 
> e) Like Simo suggested, finally how to setup an explicit permit all rule for 
> testing?

ipa hbac-add --type=allow allow_all
ipa hbac-mod --srchostcat=all allow_all
ipa hbac-mod --hostcat=all allow_all
ipa hbac-mod --usercat=all allow_all

HTH.

bye,
Sumit

> 
> Best regards,
> Oli
> 
> 
> > 
> > rob
> > 
> > > And thanks for your explanation about the sssd and sssd12 branch/repo at
> > > jdennis. It makes the difference very clear to me and I now use the
> > > sssd12 for testing (just to calm down a little bit   ;-) . Maybe a little
> > > readme.txt with your explanation would be quite nice on the server, so
> > > other people don't have to ask again.
> > >
> > > Best regards,
> > > Oli
> > >
> > > Am Mittwoch, 21. April 2010 22:41:53 schrieb Stephen Gallagher:
> > >> On 04/21/2010 02:53 PM, Oliver Burtchen wrote:
> > >>> Hi Stephen,
> > >>>
> > >>> thanks for the answer. Yes, I used the ipa-client-install tool. But I
> > >>> had
> > >
> > > first
> > >
> > >>> patched in this fix
> > >>>
> > >>> https://www.redhat.com/archives/freeipa-devel/2010-April/msg4.html
> > >>>
> > >>> from Rob to get 'join' working again. Well, living at the bleeding
> > >>> edge.
> > >
> > > ;-)
> > >
> > >>> I'll see if I can nail the problem down.
> > >>
> > >> You may find the debug logs in /var/log/sssd/. At their default settings
> > >> (level 0) these logs will display only critical errors. But if you need
> > >> more information, you can turn up the debug_level in the
> > >> /etc/sssd/sssd.conf file and restart the SSSD. Then your debug logs will
> > >> fill up fairly quickly.
> > >>
> > >> Btw., what's the difference between
> > >>
> > >>> the sssd and sssd12 repos at jdennis? What is the most recent one,
> > >>> whats
> > >
> > > best
> > >
> > >>> to use with the ipa-devel repo?
> > >>
> > >> We split the development of 1.2 off into it's own branch. Builds from
> > >> that branch are put into the sssd12 repo. We're aiming to release 1.2.0
> > >> at the beginning of May. So that's the branch targeted towards o

Re: [Freeipa-users] Is sssd currently useable with freeipa v2 ?

[Sumit Bose]

On Mon, May 03, 2010 at 10:51:10PM +0200, Oliver Burtchen wrote:
> Am Montag, 3. Mai 2010 21:17:35 schrieb Dmitri Pal:
> > Stephen Gallagher wrote:
> > > On 05/03/2010 02:55 PM, Rob Crittenden wrote:
> > >> Oliver Burtchen wrote:
> > >>> What are the exact service-names to use in --service? I know basically
> > >>> they are the ones like in /etc/services, or what pam uses. But I
> > >>> noticed that both ssh and sshd are applicable for ssh. Is there
> > >>> somewhere a list or do they provide it by their selfs, and I can only
> > >>> make a good guess and try.
> > >>
> > >> To be honest, I'm not sure myself. I'm guessing that sssd has a
> > >> mechanism for determining this. I've filed
> > >> https://bugzilla.redhat.com/show_bug.cgi?id=588412 to track this
> > >> question.
> > >
> > > I'm going to let Sumit comment on the Bugzilla ticket, since he'd know
> > > better, but I'm 99% certain that we get this directly from PAM (as in,
> > > the application itself provides that data when making a PAM request).
> > >
> > > Looking at a recent auth I performed on my system, I see the raw PAM
> > > data that comes in from (for example) 'su -l' is reported to us as
> > > "service: su-l".
> > >
> > > My assumption is that SSSD's HBAC simply treats that as canonical.
> > 
> > Thanks for reminding me. It now rings the bell. The service name is what
> > application provides when uses pam calls. There is no full enumeration.
> > It is whatever is used by an application.
> > Having a good list would be nice though, at least identifying the
> > applications that we already know use specific service names.
> > 
> 
> For the record: After reading Sumits reply at bugzilla and this
> 
> "In general, the service name is the name of the program used to access the 
> service, not the program used to provide the service. This is why the service 
> wu-ftpd, defines its service name as /etc/pam.d/ftp." quoted from
> 
> http://www.redhat.com/docs/manuals/linux/RHL-8.0-Manual/ref-guide/s1-pam-
> config-files.html
> 
> I tested it a little bit out:
> 
> If you set a hbac-rule with --service=su-l, it will only apply to "su -l" or 
> "su -", but not to a simple "su".
> 
> If you set a hbac-rule with --service=su, it will apply to "su -l", "su -"and 
> a simple "su".
> 
> So my assumption is, that applications do try from a specific name, down to 
> the 
> general one. This is why "sshd" and "ssh" work. Or is it pam who does this 
> magic?

No it is not PAM, but some kind of error on my side. The strings sssd gets
from the LDAP server are not terminated with \0, but the size is known
(this is because the ASN.1 coding of the LDAP messages). I was lazy and
just compared up to the length return by LDAP. Although the effect might
look convenient I think this is an error. I'll try to fix it tomorrow.

bye,
Sumit

> 
> Btw: I also think a good list with well known services would be nice, so 
> someone who tries to set up wu-ftpd, like the example in the redhat-docu, 
> uses 
> "ftp", and not "wu-ftpd". It's just a wish for the upcomming documentation.  
> ;-)
> 
> Best regards,
> Oli
> 
> 
> -- 
> Oliver Burtchen, Berlin
> 
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] SSS problems with eDirectory

[Sumit Bose]

On Wed, Jul 21, 2010 at 03:22:29PM -0400, Scott Duckworth wrote:

...

> 
> "something bad happened" isn't very useful.  And since SSS refuses to try
> and authenticate users without an encrypted connection, I can't easily use
> wireshark and friends to debug at the protocol level.  While I could
> probably patch the source to print the actual LDAP error with
> ldap_err2string(), or maybe gdb the process and set a breakpoint when things
> go wrong to hopefully get some more useful information, this is beyond what
> I'd normally consider doing when deploying new software.  Any suggestions?

I'm currently installing eDirectory and I will try to reproduce the
behaviour you have found.

> 
> Moving on...
> 
> We will need to dereference LDAP aliases but I have not yet been able to
> find a setting to enable this.  I also have not found the equivalent of the

I have added a RFE to sssd trac
(https://fedorahosted.org/sssd/ticket/568). As a sort term fix you can
add the appropriate DEREF option to /etc/openldap/ldap.conf.

> pam_password_prohibit_message setting in /etc/ldap.conf; while not strictly
> required, it is nice to refer users to the proper way to change passwords in
> our environment.

Currently there is only a configurable message if password resets by
root fail. I have added https://fedorahosted.org/sssd/ticket/569 to
track this.

bye,
Sumit

> 
> Any help would be appreciated.  Thanks!
> 
> Scott Duckworth, Systems Programmer II
> Clemson University School of Computing

> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] SSS problems with eDirectory

[Sumit Bose]

On Thu, Jul 22, 2010 at 10:19:37AM +0200, Sumit Bose wrote:
> On Wed, Jul 21, 2010 at 03:22:29PM -0400, Scott Duckworth wrote:
> 
> ...
> 
> > 
> > "something bad happened" isn't very useful.  And since SSS refuses to try
> > and authenticate users without an encrypted connection, I can't easily use
> > wireshark and friends to debug at the protocol level.  While I could
> > probably patch the source to print the actual LDAP error with
> > ldap_err2string(), or maybe gdb the process and set a breakpoint when things
> > go wrong to hopefully get some more useful information, this is beyond what
> > I'd normally consider doing when deploying new software.  Any suggestions?
> 
> I'm currently installing eDirectory and I will try to reproduce the
> behaviour you have found.

I have run some basic authentication test with eDirectory 8.8-SP5 and
everything worked fine. I have to admit that I have used the current
master of sssd which includes a lot of changes to the LDAP code. Would
you mind to test our current beta release from
http://kojipkgs.fedoraproject.org/packages/sssd/1.2.91/21.fc14/ . It is
for rawhide but should work fine on F13, too.

I also didn't use LDAP aliases. Can you check if setting DEREF in
/etc/openldap/ldap.conf helps? If not, can you give a short description
how aliases are used in your case so that I can set up a similar
environment?

Thanks.

bye,
Sumit

> 
> > 
> > Moving on...
> > 
> > We will need to dereference LDAP aliases but I have not yet been able to
> > find a setting to enable this.  I also have not found the equivalent of the
> 
> I have added a RFE to sssd trac
> (https://fedorahosted.org/sssd/ticket/568). As a sort term fix you can
> add the appropriate DEREF option to /etc/openldap/ldap.conf.
> 
> > pam_password_prohibit_message setting in /etc/ldap.conf; while not strictly
> > required, it is nice to refer users to the proper way to change passwords in
> > our environment.
> 
> Currently there is only a configurable message if password resets by
> root fail. I have added https://fedorahosted.org/sssd/ticket/569 to
> track this.
> 
> bye,
> Sumit
> 
> > 
> > Any help would be appreciated.  Thanks!
> > 
> > Scott Duckworth, Systems Programmer II
> > Clemson University School of Computing
> 
> > ___
> > Freeipa-users mailing list
> > Freeipa-users@redhat.com
> > https://www.redhat.com/mailman/listinfo/freeipa-users
> 
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] SSS problems with eDirectory

[Sumit Bose]

On Thu, Jul 22, 2010 at 11:19:44AM -0400, Scott Duckworth wrote:
> On Thu, Jul 22, 2010 at 11:07 AM, Sumit Bose  wrote:
> 
> > On Thu, Jul 22, 2010 at 10:19:37AM +0200, Sumit Bose wrote:
> > > On Wed, Jul 21, 2010 at 03:22:29PM -0400, Scott Duckworth wrote:
> > >
> > > ...
> > >
> > > >
> > > > "something bad happened" isn't very useful.  And since SSS refuses to
> > try
> > > > and authenticate users without an encrypted connection, I can't easily
> > use
> > > > wireshark and friends to debug at the protocol level.  While I could
> > > > probably patch the source to print the actual LDAP error with
> > > > ldap_err2string(), or maybe gdb the process and set a breakpoint when
> > things
> > > > go wrong to hopefully get some more useful information, this is beyond
> > what
> > > > I'd normally consider doing when deploying new software.  Any
> > suggestions?
> > >
> > > I'm currently installing eDirectory and I will try to reproduce the
> > > behaviour you have found.
> >
> > I have run some basic authentication test with eDirectory 8.8-SP5 and
> > everything worked fine. I have to admit that I have used the current
> > master of sssd which includes a lot of changes to the LDAP code. Would
> > you mind to test our current beta release from
> > http://kojipkgs.fedoraproject.org/packages/sssd/1.2.91/21.fc14/ . It is
> > for rawhide but should work fine on F13, too.
> >
> 
> Sure, I'll give it a shot and report back what I find.
> 
> 
> > I also didn't use LDAP aliases. Can you check if setting DEREF in
> > /etc/openldap/ldap.conf helps? If not, can you give a short description
> > how aliases are used in your case so that I can set up a similar
> > environment?
> >
> 
> Setting DEREF to always in /etc/openldap/ldap.conf works.  Aliasing is only

nice, so authentication is working for you now?

> needed for one DN in our tree: everyone's default group is aliased to
> another DN in another branch of the tree.  I wish there were some way to
> enable aliasing on a per-map basis (e.g. only groups or only users) so that
> you'd only take the performance hit where necessary, but I'm not aware of
> any NSS LDAP client that does this.
> 

The reason might be that the OpenLDAP libraries do not let you specify
the deref option in the exported ldap_search routines. It is only an
option for the whole connection.

bye,
Sumit

> 
> > Thanks.
> >
> > bye,
> > Sumit
> >
> > >
> > > >
> > > > Moving on...
> > > >
> > > > We will need to dereference LDAP aliases but I have not yet been able
> > to
> > > > find a setting to enable this.  I also have not found the equivalent of
> > the
> > >
> > > I have added a RFE to sssd trac
> > > (https://fedorahosted.org/sssd/ticket/568). As a sort term fix you can
> > > add the appropriate DEREF option to /etc/openldap/ldap.conf.
> > >
> > > > pam_password_prohibit_message setting in /etc/ldap.conf; while not
> > strictly
> > > > required, it is nice to refer users to the proper way to change
> > passwords in
> > > > our environment.
> > >
> > > Currently there is only a configurable message if password resets by
> > > root fail. I have added https://fedorahosted.org/sssd/ticket/569 to
> > > track this.
> > >
> > > bye,
> > > Sumit
> > >
> > > >
> > > > Any help would be appreciated.  Thanks!
> > > >
> > > > Scott Duckworth, Systems Programmer II
> > > > Clemson University School of Computing
> > >
> > > > ___
> > > > Freeipa-users mailing list
> > > > Freeipa-users@redhat.com
> > > > https://www.redhat.com/mailman/listinfo/freeipa-users
> > >
> > > ___
> > > Freeipa-users mailing list
> > > Freeipa-users@redhat.com
> > > https://www.redhat.com/mailman/listinfo/freeipa-users
> >
> > ___
> > Freeipa-users mailing list
> > Freeipa-users@redhat.com
> > https://www.redhat.com/mailman/listinfo/freeipa-users
> >

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] SSS problems with eDirectory

[Sumit Bose]

On Thu, Jul 22, 2010 at 04:19:53PM -0400, Scott Duckworth wrote:
> On Thu, Jul 22, 2010 at 12:38 PM, Stephen Gallagher 
> wrote:
> 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On 07/22/2010 11:47 AM, Scott Duckworth wrote:
> > >
> > > "yum localinstall libcollection-0.5.0-21.fc14.*
> > > libini_config-0.6.0-21.fc14.* sssd-1.2.91-21.fc14.*
> > > sssd-client-1.2.91-21.fc14.*" requires python 2.7.  Adding
> > > python-2.7-3.fc14.* and python-libs-2.7-3.fc14.* results in a slew of
> > > dependency resolution errors.
> > >
> > > If I get the chance in the few days, I'll try it under rawhide.
> > >
> >
> > Sorry, that was the wrong package. Please try:
> > http://koji.fedoraproject.org/koji/buildinfo?buildID=182852
> >
> > The one Sumit sent you mistakenly was from an in-progress rebuild of
> > python for Fedora 14. This one uses Python 2.6 and should install
> > cleanly on Fedora 13.
> >
> 
> Updated:
> 
> [r...@duck2 ~]# rpm -qa | grep fc14 | sort
> libcollection-0.5.0-20.fc14.i686
> libcollection-0.5.0-20.fc14.x86_64
> libdhash-0.4.0-20.fc14.i686
> libdhash-0.4.0-20.fc14.x86_64
> libini_config-0.6.0-20.fc14.i686
> libini_config-0.6.0-20.fc14.x86_64
> libpath_utils-0.2.0-20.fc14.i686
> libpath_utils-0.2.0-20.fc14.x86_64
> libref_array-0.1.0-20.fc14.i686
> libref_array-0.1.0-20.fc14.x86_64
> sssd-1.2.91-20.fc14.x86_64
> sssd-client-1.2.91-20.fc14.i686
> sssd-client-1.2.91-20.fc14.x86_64
> 
> But I'm still having the same issue.
> 
> (Thu Jul 22 16:12:49 2010) [sssd[be[CLEMSONU]]] [simple_bind_send] (4):
> Executing simple bind as: cn=SDUCKWO,ou=s,ou=EMPLOYEE,o=CLEMSONU
> (Thu Jul 22 16:12:49 2010) [sssd[be[CLEMSONU]]] [simple_bind_send] (8): ldap
> simple bind sent, msgid = 2

So the next line in the log still looks like:

(Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [sdap_process_result] (4):
ldap_result gave -1, something bad happend!

?

> 
> I have a feeling that a real LDAP error message would provide more insight
> into the situation.

Can you find anything in the server logs?

I can prepare a special build for you which prints the
LDAP_OPT_DIAGNOSTIC_MESSAGE LDAP option and let you use wireshark. But
I'm afraid this has to wait until tomorrow, it's nearly half to
midnight, here.

bye,
Sumit


> 
> - --
> > Stephen Gallagher
> > RHCE 804006346421761
> >
> > Delivering value year after year.
> > Red Hat ranks #1 in value among software vendors.
> > http://www.redhat.com/promo/vendor/
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v2.0.14 (GNU/Linux)
> > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
> >
> > iEYEARECAAYFAkxIdB8ACgkQeiVVYja6o6MpMQCfch5jTZlOHvuWaBNePVFVLK7s
> > Fg4AoItYQ6rNj8lwxwLb0pSgZfYdzhtL
> > =jdnq
> > -END PGP SIGNATURE-
> >
> > ___
> > Freeipa-users mailing list
> > Freeipa-users@redhat.com
> > https://www.redhat.com/mailman/listinfo/freeipa-users
> >

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] SSS problems with eDirectory

[Sumit Bose]

On Fri, Jul 23, 2010 at 10:49:41AM +0200, Christian Horn wrote:
> On Thu, Jul 22, 2010 at 03:30:23PM -0400, Scott Duckworth wrote:
> > 
> > There are almost 120,000 users in our directory, and we currently have ~200
> > Linux systems that might use SSSD, soon scaling to >500 systems.  I imagine
> > that even 500 systems is only a medium-scale installation compared to some
> > sites.
> 
> I recentl had a look at rhel6beta which offers sssd and nscd/nslcd.
> Had implemented ldap authorization/authentication with sssd when i dis-
> covered that netgroups are not available yet.
> Mainly used with pam_access and sudo here for authorization.
> 
> Do you mind what you are using instead in your environment?
> Or are these users just all authorized to do the same?

Netgroup support is planned for version 1.4.0 (see
https://fedorahosted.org/sssd/ticket/358).

The most flexible way of access control is to use sssd together with a
FreeIPA v2 server (the Alpha4 release was published recently). There are
also plan to add sudo support into FreeIPA (see
http://www.freeipa.org/page/SUDO_integration_plans for details).

You can use the 'simple' access control provider (see man sssd-simple)
or use sssd for users and groups and let nslcd fetch netgroups until
sssd supports it natively.

HTH

bye,
Sumit

> 
> 
> Christian
> 
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] SSS problems with eDirectory

[Sumit Bose]

On Thu, Jul 22, 2010 at 04:49:50PM -0400, Simo Sorce wrote:
> On Thu, 22 Jul 2010 16:22:45 -0400
> Scott Duckworth  wrote:
> 
> > On Thu, Jul 22, 2010 at 3:39 PM, Simo Sorce  wrote:
> > 
> > > On Thu, 22 Jul 2010 15:30:23 -0400
> > > Scott Duckworth  wrote:
> > >
> > > > On Thu, Jul 22, 2010 at 11:59 AM, Simo Sorce 
> > > > wrote:
> > > >
> > > > > On Thu, 22 Jul 2010 11:10:25 -0400
> > > > > Scott Duckworth  wrote:
> > > > >
> > > > > > I removed all files from /var/lib/sss/db/ and restarted sssd.
> > > > > > Same behavior.  nscd is disabled, so I don't think it's
> > > > > > caching at any level.
> > > > > >
> > > > > > Here is what I ran:
> > > > > >
> > > > > > [r...@duck2 ~]# getent passwd sduckwo
> > > > > > sduckwo:*:45265:1:Scott Duckworth:/home/sduckwo:/bin/bash
> > > > > > [r...@duck2 ~]# groups sduckwo
> > > > > > sduckwo : cuuser
> > > > > > [r...@duck2 ~]# getent group coes_socunix
> > > > > > coes_socunix:*:120105:sduckwo
> > > > >
> > > > >
> > > > I should add to this, that what I expected to see is this (from
> > > > one of the RHEL boxes using nss_ldap):
> > > >
> > > > [r...@potter commands]# groups sduckwo
> > > > sduckwo : cuuser coes_dpa coes_socunix coes_web_cs coes_web_fx
> > >
> > > If you log in as sduckwo you should just see that.
> > > The same if you do "id sduckwo"
> > >
> > 
> > No go...
> > 
> > [r...@duck2 ~]# service sssd stop
> > [r...@duck2 ~]# rm -f /var/lib/sss/db/*
> > [r...@duck2 ~]# service nscd stop
> > [r...@duck2 ~]# service sssd start
> > Starting sssd: [  OK  ]
> > [r...@duck2 ~]# id sduckwo
> > uid=45265(sduckwo) gid=1(cuuser) groups=1(cuuser)
> > [r...@duck2 ~]# su - sduckwo
> > [16:05:24] sduc...@duck2:~ [1] id
> > uid=45265(sduckwo) gid=1(cuuser) groups=1(cuuser)
> > [16:05:26] sduc...@duck2:~ [2] groups
> > cuuser
> 
> Uhmmm this may be a side effect of your directory not having memberof
> I think we need to add special code to handle servers that use
> rfc2307bis schema but that do not use memberof.

In my test setup eDirectory uses an attribute named groupMembership in
the user object to store the DN of the groups the user belongs to. Can
you check if adding the option

ldap_user_member_of = groupMembership

does help here?

bye,
Sumit

> 
> > I'm unable to actually login due to pam_sss not working (see another
> > branch of this thread).
> 
> Yes, I think we need to file a few bugs and add support for servers
> like yours.
> 
> > > Of cours when a user logs in its information (including its group
> > > > > membership) is refreshed and validated, so at login time the
> > > > > membership is correctly updated for that user across all its
> > > > > groups.
> > > > >
> > > >
> > > > This seems to contradict your statement above, and also the
> > > > behavior I'm seeing.  It's not picking up secondary group
> > > > memberships unless they've already been cached, either through an
> > > > explicit getent or, presumably (if it ever finishes), via
> > > > enumeration.
> > >
> > > Your configuration showed that enumeration is disabled (as it should
> > > be), have you changed that ?
> > >
> > 
> > I did enable enumeration per what I thought was your previous
> > suggestion. I've now disabled it again.  To be clear, my current
> > sssd.conf is:
> > 
> > [sssd]
> > config_file_version = 2
> > reconnection_retries = 3
> > sbus_timeout = 30
> > services = nss, pam
> > domains = CLEMSONU
> > [nss]
> > debug_level = 7
> > filter_groups = root
> > filter_users = root
> > reconnection_retries = 3
> > entry_cache_timeout = 1
> > entry_cache_nowait_timeout = 1
> > [pam]
> > debug_level = 7
> > reconnection_retries = 3
> > [domain/CLEMSONU]
> > debug_level = 20
> > enumerate = False
> > cache_credentials = False
> > id_provider = ldap
> > auth_provider = ldap
> > ldap_schema = rfc2307bis
> > chpass_provider = ldap
> > min_id = 1000
> > ldap_uri = ldaps://clemsonuldap.clemson.edu
> > ldap_id_use_start_tls = False
> > ldap_tls_cacertdir = /etc/openldap/cacerts
> > tls_reqcert = demand
> > ldap_default_bind_dn = cn=CoESProxy,ou=proxyUsers,o=CLEMSONU
> > ldap_default_authtok_type = password
> > ldap_default_authtok = xx
> > ldap_search_base = ou=SoC,ou=CES,o=CLEMSONU
> > ldap_user_search_base = o=CLEMSONU
> > ldap_group_search_base = o=CLEMSONU
> > ldap_user_shell = coesLoginShell
> > ldap_user_gecos = fullName
> > ldap_user_fullname = fullName
> > ldap_pwd_policy = none
> > 
> > and /etc/openldap/ldap.conf is:
> > 
> > DEREF   always
> > URI ldaps://clemsonuldap.clemson.edu
> > BASE ou=SoC,ou=CES,o=CLEMSONU
> > TLS_CACERTDIR /etc/openldap/cacerts
> > 
> > 
> > > If you are witnessing long dealys on login then you are hitting the
> > > initgroups problem we are going to fix shortly.
> > >
> > 
> > I believe the long delays were caused by enumeration.  There are no
> > such delays with enumeration disabled.
> 
> yes, it is expected that enumeration is quite heavy, as it has to query
> all users and grou

Re: [Freeipa-users] limit access to a specific CN

[Sumit Bose]

On Tue, Feb 15, 2011 at 06:30:51PM -0500, Peter Doherty wrote:
> 
> On Feb 15, 2011, at 14:45 , Simo Sorce wrote:
> 
> > On Tue, 15 Feb 2011 14:09:07 -0500
> > Peter Doherty  wrote:
> > 
> >> On Feb 15, 2011, at 14:02 , Rob Crittenden wrote:
> >> 
> >>> Peter Doherty wrote:
>  Hello,  I'm running Fedora 14 and freeipa 1.2.2-6
>  
>  
>  Can I create a new cn/nsContainer (cn=subgroup,dc=example,dc=com)
>  and then create an account that can edit that cn as much as they  
>  want,
>  
>  
> >>> 
> >>> What would you put into this container?
> >>> 
> >>> 
> >>> 
> >>> rob
> >> 
> >> The first thing I'm looking to do with it is have a web server that  
> >> has account information stored in LDAP, and to allow users to to
> >> ldap authentication.  The users logging into the web server would be  
> >> 
> > 
> > It is possible to do using LDAP tools and then setting an ACI on the
> > container to give the user you want full control on that container.
> > 
> > Simo.
> 
> Simo, 
> 
> This gave me a good starting point, and after reading some more, I'm starting 
> to wrap my brain around what I want to do and how to do it.
> LDAP has a steep learning curve, IMHO.
> Can you recommend any GUI tools for creating/modifying the ACI for the 
> container?  I started to try and create an ACI using the ones within FreeIPA 
> as a reference, but if there's a GUI that would be useful too.  I checked out 
> Apache Directory Studio which looks nice, but doesn't seem to support the 
> schema that FreeIPA is using.

I use Apache Directory Studio to edit FreeIPA LDAP objects and I can
also see and edit ACIs. The schema shouldn't be a problem, because the
editor can read the schema data from the LDAP server. Which kind of
problems are you seeing ?

bye,
Sumit

> 
> --Peter
> 
> 
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] limit access to a specific CN

[Sumit Bose]

On Wed, Feb 16, 2011 at 09:28:10AM -0500, Peter Doherty wrote:
> 
> On Feb 16, 2011, at 04:10 , Sumit Bose wrote:
> 
> >On Tue, Feb 15, 2011 at 06:30:51PM -0500, Peter Doherty wrote:
> >>
> >>On Feb 15, 2011, at 14:45 , Simo Sorce wrote:
> >>
> >>>On Tue, 15 Feb 2011 14:09:07 -0500
> >>>Peter Doherty  wrote:
> >>>
> >>>>On Feb 15, 2011, at 14:02 , Rob Crittenden wrote:
> >>>>
> >>>>>Peter Doherty wrote:
> >>>>>>Hello,  I'm running Fedora 14 and freeipa 1.2.2-6
> >>>>>>
> >>>>>>
> >>>>>>Can I create a new cn/nsContainer (cn=subgroup,dc=example,dc=com)
> >>>>>>and then create an account that can edit that cn as much as they
> >>>>>>want,
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>What would you put into this container?
> >>>>>
> >>>>>
> >>>>>
> >>>>>rob
> >>>>
> >>>>The first thing I'm looking to do with it is have a web server that
> >>>>has account information stored in LDAP, and to allow users to to
> >>>>ldap authentication.  The users logging into the web server
> >>>>would be
> >>>>
> >>>
> >>>It is possible to do using LDAP tools and then setting an ACI on the
> >>>container to give the user you want full control on that container.
> >>>
> >>>Simo.
> >>
> >>Simo,
> >>
> >>This gave me a good starting point, and after reading some more,
> >>I'm starting to wrap my brain around what I want to do and how
> >>to do it.
> >>LDAP has a steep learning curve, IMHO.
> >>Can you recommend any GUI tools for creating/modifying the ACI
> >>for the container?  I started to try and create an ACI using the
> >>ones within FreeIPA as a reference, but if there's a GUI that
> >>would be useful too.  I checked out Apache Directory Studio
> >>which looks nice, but doesn't seem to support the schema that
> >>FreeIPA is using.
> >
> >I use Apache Directory Studio to edit FreeIPA LDAP objects and I can
> >also see and edit ACIs. The schema shouldn't be a problem, because the
> >editor can read the schema data from the LDAP server. Which kind of
> >problems are you seeing ?
> 
> Well, Apache Directory Studio has ACI editor (looks like this:
> http://directory.apache.org/studio/screenshots.data/aci_visual_1.png
> )
> so you don't edit the text directly, but rather use a GUI, which
> builds the policy in text and inserts it when you're done editing.
> But it seems to use a different schema than FreeIPA is using...

This plugin is for Apache Directory Server only. AFAIK there is nothing
like a standard for ACIs in directory servers and so every directory
server has his own concept of access control.

bye,
Sumit

> 
> Peter

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] sssd options ignored?

[Sumit Bose]

On Wed, Mar 18, 2015 at 08:41:30AM +0100, Jakub Hrozek wrote:
> On Wed, Mar 18, 2015 at 08:26:03AM +0200, Alexander Bokovoy wrote:
> > On Tue, 17 Mar 2015, Gould, Joshua wrote:
> > >I figured out that the ldap_idmap_range_min and ldap_idmap_range_size need
> > >to match whats in ipa idrange-find --all for the AD domain.
> > >
> > ># ipa idrange-mod --base-id=10 --range-size=90 --rid-base=0
> > >Range name: TEST.OSUWMC_id_range
> > >
> > >Modified ID range "TEST.OSUWMC_id_range"
> > >
> > >Range name: TEST.OSUWMC_id_range
> > >First Posix ID of the range: 10
> > >Number of IDs in the range: 90
> > >First RID of the corresponding RID range: 0
> > >Domain SID of the trusted domain: S-1-5-21-226267946-722566613-1883572810
> > >Range type: Active Directory domain range
> > >
> > >
> > >/etc/sssd/sssd.conf:
> > >[domain/test.osuwmc]
> > >ldap_idmap_range_min = 10
> > >ldap_idmap_range_size = 90
> > There is something completely broken here.
> 
> Yes, the sssd.conf configuration :-)
> 
> SSSD will not even read this sssd.conf section, it is just ignored. The
> subdomains are mostly auto-configured, just with several exceptions
> (like subdomain_homedir) where we read the subdomain config from the
> main domain config.
> 
> > You *shouldn't* need to add a
> > separate domain section for any of the domains coming over the forest
> > trust link path _at_all_. SSSD automatically derives all needed
> > parameters for them via its IPA providers for the primary IPA domain.
> > 
> > Jakub, what is going on?
> 
> I would prefer if also Sumit can add his opinon since he authored the ID
> mapping code.

as Alexander said in the other thread, only the IPA domain should be
configured if you want to use IPA and trust. AD domains will be
discovered and ranges will be configured on the IPA server side and IPA
clients will get all information about trusted AD domains from the IPA
server.

So, please remove the section for the AD completely from sssd.conf.

HTH

bye,
Sumit
> 
> But here's how I see it - since you use 'external ID mapping', then you
> should just rely on the properties from the server. The only action to
> take on the client side is to purge the sssd cache on the clients if the
> ID mapping changes, because currently SSSD doesn't handle ID changes.
> 
> And because gracefully handling ID changes is not planned even for the
> next version (1.13), I wonder if it makes sense to add a warning after
> idrange-mod command is run that it's preferable to clean the caches? We
> might also want to add some kind of simple CLI tool (sss_delcache?) so
> that admins don't have to learn where are the caches stored.
> 
> -- 
> 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

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

Re: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode

[Sumit Bose]

On Thu, Mar 19, 2015 at 04:46:44PM +0100, Bobby Prins wrote:
> Hi there,
> 
> I'm currently trying to use the 'AD Trust for Legacy Clients' freeIPA setup 
> (described here: 
> http://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf) to be able 
> to autenticate AIX 7.1 clients against an AD domain using LDAP. After the 
> trust was created all seems to work well on the freeIPA server. I can also do 
> a lookup of AD users and groups on an AIX test server.
> 
> But as soon as I want to log in on the AIX system I get an SSSD error on the 
> freeIPA server in krb5_child.log (debug_level = 10):
> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590260: AS key 
> obtained for encrypted timestamp: aes256-cts/2F5D
> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590326: Encrypted 
> timestamp (for 1426778442.525165): plain 
> 301AA011180F32303135303331393135323034325AA105020308036D, encrypted 
> 9B3299264F09E50D63D84B385A09A4C64D44116A02B58FFF12830B39F88722CD9B792F5ABA0653578DE9138B91D29C17C197453D8B8A5E7A
> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590349: Preauth module 
> encrypted_timestamp (2) (flags=1) returned: 0/Success
> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590360: Produced 
> preauth for next request: 2
> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590384: Sending 
> request (238 bytes) to EXAMPLE.CORP
> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.591325: Resolving 
> hostname dct020.example.corp.
> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.591889: Sending 
> initial UDP request to dgram 192.168.143.1:88
> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636127: Received 
> answer from dgram 192.168.143.1:88
> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636626: Response was 
> not from master KDC
> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636667: Received error 
> from KDC: -1765328360/Preauthentication failed
> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636698: Preauth 
> tryagain input types: 16, 14, 19, 2
> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636728: Retrying AS 
> request with master KDC
> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636741: Getting 
> initial credentials for bpr...@example.corp
> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636787: Sending 
> request (160 bytes) to EXAMPLE.CORP (master)
> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 [get_and_save_tgt] 
> (0x0020): 979: [-1765328360][Preauthentication failed]
> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 [map_krb5_error] 
> (0x0020): 1040: [-1765328360][Preauthentication failed]
> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 [k5c_send_data] 
> (0x0200): Received error code 1432158214
> 
> If I do the same with 'KRB5_TRACE=/dev/stderr kinit bpr...@example.corp':
> [12299] 1426773524.361785: AS key obtained for encrypted timestamp: 
> aes256-cts/B997
> [12299] 1426773524.361850: Encrypted timestamp (for 1426773524.277583): plain 
> 301AA011180F32303135303331393133353834345AA1050203043C4F, encrypted 
> ED9CF995617740C4B14DB9CC84187E3505B664FE5C0AD16D19477E912F5400FB2C4665A090E3A37CD749535B3C80595809E14D15CB3527C0
> [12299] 1426773524.361876: Preauth module encrypted_timestamp (2) (flags=1) 
> returned: 0/Success
> [12299] 1426773524.361880: Produced preauth for next request: 2
> [12299] 1426773524.361901: Sending request (238 bytes) to EXAMPLE.CORP
> [12299] 1426773524.363002: Resolving hostname dct020.EXAMPLE.corp.
> [12299] 1426773524.363841: Sending initial UDP request to dgram 
> 192.168.141.1:88
> [12299] 1426773524.368089: Received answer from dgram 192.168.141.1:88
> [12299] 1426773524.368482: Response was not from master KDC
> [12299] 1426773524.368500: Received error from KDC: -1765328332/Response too 
> big for UDP, retry with TCP
> [12299] 1426773524.368506: Request or response is too big for UDP; retrying 
> with TCP
> [12299] 1426773524.368511: Sending request (238 bytes) to EXAMPLE.CORP (tcp 
> only)
> [12299] 1426773524.368953: Resolving hostname dct030.EXAMPLE.corp.
> [12299] 1426773524.370056: Initiating TCP connection to st

Re: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode

[Sumit Bose]

On Fri, Mar 20, 2015 at 11:44:43AM +0100, Bobby Prins wrote:
> On Thu, Mar 19, 2015 at 04:46:44PM +0100, Bobby Prins wrote:
> >> Hi there,
> >> 
> >> I'm currently trying to use the 'AD Trust for Legacy Clients' freeIPA 
> >> setup (described here: 
> >> http://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf) to be 
> >> able to autenticate AIX 7.1 clients against an AD domain using LDAP. After 
> >> the trust was created all seems to work well on the freeIPA server. I can 
> >> also do a lookup of AD users and groups on an AIX test server.
> >> 
> >> But as soon as I want to log in on the AIX system I get an SSSD error on 
> >> the freeIPA server in krb5_child.log (debug_level = 10):
> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
> >> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590260: AS key 
> >> obtained for encrypted timestamp: aes256-cts/2F5D
> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
> >> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590326: Encrypted 
> >> timestamp (for 1426778442.525165): plain 
> >> 301AA011180F32303135303331393135323034325AA105020308036D, encrypted 
> >> 9B3299264F09E50D63D84B385A09A4C64D44116A02B58FFF12830B39F88722CD9B792F5ABA0653578DE9138B91D29C17C197453D8B8A5E7A
> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
> >> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590349: Preauth 
> >> module encrypted_timestamp (2) (flags=1) returned: 0/Success
> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
> >> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590360: Produced 
> >> preauth for next request: 2
> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
> >> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590384: Sending 
> >> request (238 bytes) to EXAMPLE.CORP
> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
> >> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.591325: Resolving 
> >> hostname dct020.example.corp.
> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
> >> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.591889: Sending 
> >> initial UDP request to dgram 192.168.143.1:88
> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
> >> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636127: Received 
> >> answer from dgram 192.168.143.1:88
> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
> >> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636626: Response 
> >> was not from master KDC
> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
> >> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636667: Received 
> >> error from KDC: -1765328360/Preauthentication failed
> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
> >> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636698: Preauth 
> >> tryagain input types: 16, 14, 19, 2
> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
> >> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636728: Retrying AS 
> >> request with master KDC
> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
> >> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636741: Getting 
> >> initial credentials for bpr...@example.corp
> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
> >> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636787: Sending 
> >> request (160 bytes) to EXAMPLE.CORP (master)
> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 [get_and_save_tgt] 
> >> (0x0020): 979: [-1765328360][Preauthentication failed]
> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 [map_krb5_error] 
> >> (0x0020): 1040: [-1765328360][Preauthentication failed]
> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 [k5c_send_data] 
> >> (0x0200): Received error code 1432158214
> >> 
> >> If I do the same with 'KRB5_TRACE=/dev/stderr kinit bpr...@example.corp':
> >> [12299] 1426773524.361785: AS key obtained for encrypted timestamp: 
> >> aes256-cts/B997
> >> [12299] 1426773524.361850: Encrypted timestamp (for 1426773524.277583): 
> >> plain 301AA011180F32303135303331393133353834345AA1050203043C4F, encrypted 
> >> ED9CF995617740C4B14DB9CC84187E3505B664FE5C0AD16D19477E912F5400FB2C4665A090E3A37CD749535B3C80595809E14D15CB3527C0
> >> [12299] 1426773524.361876: Preauth module encrypted_timestamp (2) 
> >> (flags=1) returned: 0/Success
> >> [12299] 1426773524.361880: Produced preauth for next request: 2
> >> [12299] 1426773524.361901: Sending request (238 bytes) to EXAMPLE.CORP
> >> [12299] 1426773524.363002: Resolving hostname dct020.EXAMPLE.corp.
> >> [12299] 1426773524.363841: Sending initial UDP request to dgram 
> >> 192.168.141.1:88
> >> [12299] 1426773524.368089: Received answer from dgram 192.168.141.1:88
> >> [12299] 1426773524.368482: Response was not from master KDC
> >> [12299] 1426773524.368500: Received error from KDC: -1765328332/Response 
> >> too big for UDP, retry with TCP
> >> [

Re: [Freeipa-users] Clients are reading AD info inconsistently

[Sumit Bose]

On Wed, Mar 25, 2015 at 08:01:36PM -0400, Dmitri Pal wrote:
> On 03/25/2015 11:44 AM, Simo Sorce wrote:
> >On Wed, 2015-03-25 at 14:46 +, Guertin, David S. wrote:
> >>Follow-up: today I tried clearing the sssd cache and restarting sssd on all 
> >>three clients, and all three lost their AD users:
> >>
> >># rm -f /var/lib/sss/db/*
> >># service sssd restart
> >>Stopping sssd: [  OK  ]
> >>Starting sssd: [  OK  ]
> >># id 'MIDD\juser'
> >>id: MIDD\juser: No such user
> >>
> >>David Guertin
> >>
> >This is normal, users are "loaded in" when they actually try to Log In.
> >
> >Simo.
> >
> Yes. The ability to look up AD users that never authenticated was added in
> 7.1 and 6.7 (i.e. SSSD 1.12)

I would like to just clarify tis a bit. The support to lookup up
secondary groups (the group list the id command shows) for user which
never authenticated was added in 7.1/6.7.

The plain user lookup as e.g. done with the 'getent passwd username'
always worked.

David, the IPA clients will connect the IPA server to get the user data.
This means if the server cannot resolve the user the clients cannot
either. So the IPA server should be checked first.

You said that you have three IPA servers (master and replicas). Did you
run ipa-adtrust-install on all server? If not, please do. If you are not
sure, running ipa-adtrust-install multiple times does not so any harm.

 Since you are using RHEL-6 clients I assume your IPA servers are on
RHEL-6 as well. In this case please try if the command

wbinfo -n 'MIDD\juser'

returns the SID of the user on the IPA server.

HTH

bye,
Sumit

> 
> -- 
> Thank you,
> Dmitri Pal
> 
> Sr. Engineering Manager IdM portfolio
> Red Hat, Inc.
> 
> -- 
> 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

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

Re: [Freeipa-users] Clients are reading AD info inconsistently

[Sumit Bose]

On Thu, Mar 26, 2015 at 03:24:06PM +, Guertin, David S. wrote:
> >I would like to just clarify tis a bit. The support to lookup up secondary 
> >groups
> >(the group list the id command shows) for user which never authenticated
> >was added in 7.1/6.7.
> 
> Thanks. This makes sense, and indeed with Client 1 I can indeed log in, and 
> "id 'MIDD\juser'" shows all the groups again.
> 
> However, logins to Client 2 (also running RHEL 6.6 and sssd 1.11.6) still 
> fail, and "id 'MIDD\juser'" on that client shows only local IPA groups, not 
> AD groups.

As long as the user has not logged in it is expected that the id command
doe not show the full list of groups. To see why the login fails it
would be good to know how you try to log in (I assume ssh) and which
authentication method is used (password, ssh key, Kerberos ticket).
Additionally the SSSD log files might be needed, most important here are
the logs from the PAM and PAC responders and the domain log.

> 
> And logins to Client 3 also fail, and "id 'MIDD\juser'" there shows "No such 
> user". (This is the RHEL 5 box with sssd 1.5.1.) So we're back to my original 
> problem of three clients all behaving differently.

For RHEL5 you need a special configuration for SSSD, call 'ipa-advise
config-redhat-sssd-before-1-9' for more details.

HTH

bye,
Sumit

> 
> >David, the IPA clients will connect the IPA server to get the user data.
> >This means if the server cannot resolve the user the clients cannot either. 
> >So
> >the IPA server should be checked first.
> 
> All three servers can resolve the user. The user can log in to all the 
> servers and "id 'MIDD\juser'" shows the correct AD groups.
> 
> >You said that you have three IPA servers (master and replicas). Did you run
> >ipa-adtrust-install on all server? If not, please do. If you are not sure, 
> >running
> >ipa-adtrust-install multiple times does not so any harm.
> 
> Yes, the trust relationship is set up correctly on all three servers, and 
> "ipa trust-find --all" gives identical results on all three servers, 
> correctly showing the trust relationship with our AD domain.
> 
> > Since you are using RHEL-6 clients I assume your IPA servers are on
> >RHEL-6 as well. 
> 
> No, the servers are all running RHEL 7.1, so we're not using winbind at all 
> -- just sssd.
> 
> The clients are a mix of RHEL 6 and RHEL 5 machines.
> 
> David Guertin

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

Re: [Freeipa-users] Clients are reading AD info inconsistently

[Sumit Bose]

On Fri, Mar 27, 2015 at 02:23:27PM +, Guertin, David S. wrote:
> >To see why the login fails it would be good to
> >know how you try to log in (I assume ssh) and which authentication method
> >is used (password, ssh key, Kerberos ticket).
> >Additionally the SSSD log files might be needed, most important here are the
> >logs from the PAM and PAC responders and the domain log.
> 
> Yes, this is SSH. There are a few hints in the log files on the client:
> 
> sssd_ipa.middlebury.edu.log:
> 
> (Fri Mar 27 09:29:14 2015) [sssd[be[ipa.middlebury.edu]]] [ipa_s2n_exop_send] 
> (0x0400): Executing extended operation
> (Fri Mar 27 09:29:14 2015) [sssd[be[ipa.middlebury.edu]]] [ipa_s2n_exop_send] 
> (0x2000): ldap_extended_operation sent, msgid = 12
> (Fri Mar 27 09:29:14 2015) [sssd[be[ipa.middlebury.edu]]] 
> [sdap_process_result] (0x2000): Trace: sh[0xe7f410], connected[1], 
> ops[0xe80680], ldap[0xe641d0]
> (Fri Mar 27 09:29:14 2015) [sssd[be[ipa.middlebury.edu]]] 
> [sdap_process_message] (0x4000): Message type: [LDAP_RES_EXTENDED]
> (Fri Mar 27 09:29:14 2015) [sssd[be[ipa.middlebury.edu]]] [ipa_s2n_exop_done] 
> (0x0400): ldap_extended_operation result: Protocol error(2), (null)

The most likely reason for 'Protocol error' is that the server this
client is connected to does not support the special LDAP extended
operation used by SSSD on IPA clients to get the data for users and
groups from trusted domains. And the most likely reason for this is that
ipa-adtrust-install is not run on that server. Please note that while
'ipa trust-add ...' must be only run once on one of the IPA servers,
ipa-adtrust-install must be run on all, e.g. to enable the LDAP extended
operation mentioned above.

You can check if the exop is enabled on the servers by running

ldapsearch -h localhost -x -b '' -s base|grep 2.16.840.1.113730.3.8.10.4

on each server. YOu should see 1, for RHEL-7.1 even 2 lines of output.

> (Fri Mar 27 09:29:14 2015) [sssd[be[ipa.middlebury.edu]]] 
> [ipa_s2n_get_user_done] (0x0040): s2n exop request failed.
> (Fri Mar 27 09:29:14 2015) [sssd[be[ipa.middlebury.edu]]] [sdap_id_op_done] 
> (0x4000): releasing operation connection
> (Fri Mar 27 09:29:14 2015) [sssd[be[ipa.middlebury.edu]]] [acctinfo_callback] 
> (0x0100): Request processed. Returned 3,1432158221,Account info lookup failed
> (Fri Mar 27 09:29:14 2015) [sssd[be[ipa.middlebury.edu]]] 
> [sdap_process_result] (0x2000): Trace: sh[0xe7f410], connected[1], 
> ops[(nil)], ldap[0xe641d0]
> 
> Sssd_nss.log:
> 
> (Fri Mar 27 09:29:14 2015) [sssd[nss]] [sss_dp_issue_request] (0x0400): 
> Issuing request for [0x418850:1:ju...@middlebury.edu]
> (Fri Mar 27 09:29:14 2015) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): 
> Creating request for [middlebury.edu][4097][1][name=juser]
> (Fri Mar 27 09:29:14 2015) [sssd[nss]] [sbus_add_timeout] (0x2000): 0x6b5a10
> (Fri Mar 27 09:29:14 2015) [sssd[nss]] [sss_dp_internal_get_send] (0x0400): 
> Entering request [0x418850:1:ju...@middlebury.edu]
> (Fri Mar 27 09:29:14 2015) [sssd[nss]] [sbus_remove_timeout] (0x2000): 
> 0x6b5a10
> (Fri Mar 27 09:29:14 2015) [sssd[nss]] [sbus_dispatch] (0x4000): dbus conn: 
> 0x6b0aa0
> (Fri Mar 27 09:29:14 2015) [sssd[nss]] [sbus_dispatch] (0x4000): Dispatching.
> (Fri Mar 27 09:29:14 2015) [sssd[nss]] [sss_dp_get_reply] (0x1000): Got reply 
> from Data Provider - DP error code: 3 errno: 1432158221 error message: 
> Account info lookup failed
> (Fri Mar 27 09:29:14 2015) [sssd[nss]] [nss_cmd_getby_dp_callback] (0x0040): 
> Unable to get information from Data Provider
> Error: 3, 1432158221, Account info lookup failed
> Will try to return what we have in cache
> (Fri Mar 27 09:29:14 2015) [sssd[nss]] [sss_dp_req_destructor] (0x0400): 
> Deleting request: [0x418850:1:ju...@middlebury.edu]
> 
> I don't see any errors in sssd_pam.log, sssd_pac.log, or sssd_ssh.log.
> 
> Is this an indication that something is wrong with the trust relationship? If 
> so, why is it happening on this client but not the other one? Any why are the 
> servers working properly?

Maybe the clients are connected to different servers and only one of
them has the exop enabled? The servers itself lookup the AD users and
groups directly from the AD DC. Since the users are available on the
server and one client is already working I expect that the trust
relationship is fine.

HTH

bye,
Sumit

> 
> David Guertin

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

Re: [Freeipa-users] Clients are reading AD info inconsistently

[Sumit Bose]

On Fri, Mar 27, 2015 at 05:16:20PM +, Guertin, David S. wrote:
> >The most likely reason for 'Protocol error' is that the server this client is
> >connected to does not support the special LDAP extended operation used by
> >SSSD on IPA clients to get the data for users and groups from trusted
> >domains. And the most likely reason for this is that ipa-adtrust-install is 
> >not
> >run on that server. Please note that while 'ipa trust-add ...' must be only 
> >run
> >once on one of the IPA servers, ipa-adtrust-install must be run on all, e.g. 
> >to
> >enable the LDAP extended operation mentioned above.
> >
> >You can check if the exop is enabled on the servers by running
> >
> >ldapsearch -h localhost -x -b '' -s base|grep 2.16.840.1.113730.3.8.10.4
> >
> >on each server. YOu should see 1, for RHEL-7.1 even 2 lines of output.
> 
> You are correct; I had not run ipa-adtrust-install on the replica servers. I 
> have done that, and now the 
> ldapsearch command works correctly and the "Protocol error" statement is gone 
> from the logs. But 
> there was something else going on and users still could not log in to the 
> client.
> 
> The log files indicated that there was a permissions problem with /tmp. I 
> changed it to root: root 777, and 
> now logins are working. Thanks!

Thank you for the feedback. Please note that /tmp/ should be 1777
(sticky bit set) so that only owners can delete files.

bye,
Sumit

> 
> David Guertin
> 

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

Re: [Freeipa-users] Additional pre-authentication required, Ticket Wrong ?

[Sumit Bose]

On Mon, Mar 30, 2015 at 04:56:11AM +0200, Matt . wrote:
> Hi,
> 
> I just tot home and typing from my cell so i'm suite short in words
> 
> Create keytab for ldap-01.domain
> Kinit with that to ldap.domain
> Curl against ldap.domain
> Get a 301 which I manage from curl (goes well)
> Get kerberos ticket error
> 
> now I don't kinit anymore so re-use my existing ticket and curl against
> ldap-01.domain and I'm accepted and can execute stuff.
> 
> My ssl is OK, ticket also it seems.

Maybe the output of

KRB5_TRACE=/dev/sdtout curl -v 

might help to see what is going on? 

bye,
Sumit

> 
> Thanks M.
> Op 30 mrt. 2015 03:50 schreef "Dmitri Pal" :
> 
> > On 03/29/2015 04:47 AM, Matt . wrote:
> >
> >> Hi Guys,
> >>
> >> Now my Certification issues are solved for using a loadbalancer in
> >> front of my ipa servers I get the following:
> >>
> >> Unable to verify your Kerberos credentials
> >>
> >> and in my logs:
> >>
> >> Additional pre-authentication required.
> >>
> >> This happens when I connect throught my loadbalancers, I see my server
> >> coming ni with the right IP.
> >>
> >> When I access my ipa server directly, not using the loadbalancer IP
> >> between it, my kerberos Ticket is valid.
> >>
> >> I get the feeling that when I use my loadbalancers and because of that
> >> I get a 301 redirect it needs a preauth. I see some issues on
> >> mailinglists but it doesn't fit my situation.
> >>
> >> Why wants it the preauth when I already have a valid ticket and my
> >> redirect is followed by CURL and posted the right way ?
> >>
> >
> > Can you describe the sequence?
> > What do you do?
> >
> > From the client you try IPA CLI and this is where you see the problem even
> > with the valid ticket or is the flow different?
> >
> >  I hope someone has an idea.
> >>
> >> Thanks,
> >>
> >> Matt
> >>
> >>
> >
> > --
> > Thank you,
> > Dmitri Pal
> >
> > Sr. Engineering Manager IdM portfolio
> > Red Hat, Inc.
> >
> > --
> > 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
> >

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

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

Re: [Freeipa-users] Troubleshooting SSO

[Sumit Bose]

On Mon, Mar 30, 2015 at 09:08:54AM -0400, Gould, Joshua wrote:
> SSO works intermittently. I’m having trouble tracing the issue. Here is what 
> I see from /var/log/secure. Where should I look for more detail to figure out 
> why the SSO login is failing?

assuming you have a valid Kerberos ticket the most probable reason is
that libkrb5 cannot properly relate the Kerberos principal from the
ticket to the local user name you use at the login prompt. With DEBUG3
you should see some messages containing '*userok*'. If you see failures
related to these messages it most probable is this case.

Recent versions of SSSD will configure a plugin for libkrb5 which can
handle this. But for older version you either have to create a .k5login
file in the users home directory containing the Kerberos principal or
use auth_to_local directives in /etc/krb5.conf as described in
http://www.freeipa.org/page/Active_Directory_trust_setup#Edit_.2Fetc.2Fkrb5.conf

HTH

bye,
Sumit

> 
> Mar 30 08:47:39 mid-ipa-vp01 sshd[9317]: Starting session: shell on pts/0 for 
> root from 10.34.149.105 port 49725
> Mar 30 08:47:39 mid-ipa-vp01 sshd[9322]: debug1: Setting controlling tty 
> using TIOCSCTTY.
> Mar 30 08:47:39 mid-ipa-vp01 sshd[9322]: debug1: PAM: reinitializing 
> credentials
> Mar 30 08:47:39 mid-ipa-vp01 sshd[9322]: debug1: permanently_set_uid: 0/0
> Mar 30 08:49:05 mid-ipa-vp01 sshd[9317]: debug1: server_input_global_request: 
> rtype keepal...@openssh.com want_reply 1
> Mar 30 08:50:05 mid-ipa-vp01 sshd[9317]: debug1: server_input_global_request: 
> rtype keepal...@openssh.com want_reply 1
> Mar 30 08:51:57 mid-ipa-vp01 sshd[9317]: debug1: server_input_global_request: 
> rtype keepal...@openssh.com want_reply 1
> Mar 30 08:52:57 mid-ipa-vp01 sshd[9317]: debug1: server_input_global_request: 
> rtype keepal...@openssh.com want_reply 1
> Mar 30 08:53:51 mid-ipa-vp01 sshd[1388]: debug1: Forked child 12621.
> Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: Set /proc/self/oom_score_adj to 0
> Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: rexec start in 5 out 5 
> newsock 5 pipe 7 sock 8
> Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: inetd sockets after 
> dupping: 3, 3
> Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: Connection from 10.80.5.239 port 
> 52982 on 10.127.26.73 port 22
> Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: Client protocol version 
> 2.0; client software version PuTTY_Release_0.64
> Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: no match: PuTTY_Release_0.64
> Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: Enabling compatibility mode 
> for protocol 2.0
> Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: Local version string 
> SSH-2.0-OpenSSH_6.6.1
> Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: SELinux support enabled 
> [preauth]
> Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: permanently_set_uid: 74/74 
> [preauth]
> Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: list_hostkey_types: 
> ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
> Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: SSH2_MSG_KEXINIT sent 
> [preauth]
> Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: SSH2_MSG_KEXINIT received 
> [preauth]
> Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: kex: client->server 
> aes256-ctr hmac-sha2-256 none [preauth]
> Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: kex: server->client 
> aes256-ctr hmac-sha2-256 none [preauth]
> Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: kex: 
> diffie-hellman-group-exchange-sha256 need=32 dh_need=32 [preauth]
> Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: kex: 
> diffie-hellman-group-exchange-sha256 need=32 dh_need=32 [preauth]
> Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: 
> SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received [preauth]
> Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: SSH2_MSG_KEX_DH_GEX_GROUP 
> sent [preauth]
> Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: expecting 
> SSH2_MSG_KEX_DH_GEX_INIT [preauth]
> Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: SSH2_MSG_KEX_DH_GEX_REPLY 
> sent [preauth]
> Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: SSH2_MSG_NEWKEYS sent 
> [preauth]
> Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: expecting SSH2_MSG_NEWKEYS 
> [preauth]
> Mar 30 08:53:52 mid-ipa-vp01 sshd[12621]: debug1: SSH2_MSG_NEWKEYS received 
> [preauth]
> Mar 30 08:53:52 mid-ipa-vp01 sshd[12621]: debug1: KEX done [preauth]
> Mar 30 08:53:52 mid-ipa-vp01 sshd[12621]: debug1: userauth-request for user 
> adm-faru03@test.osuwmc service ssh-connection method none [preauth]
> Mar 30 08:53:52 mid-ipa-vp01 sshd[12621]: debug1: attempt 0 failures 0 
> [preauth]
> Mar 30 08:53:53 mid-ipa-vp01 sshd[12621]: debug1: PAM: initializing for 
> "adm-faru03@test.osuwmc"
> Mar 30 08:53:53 mid-ipa-vp01 sshd[12621]: debug1: PAM: setting PAM_RHOST to 
> "svr-addc-vt01.test.osuwmc"
> Mar 30 08:53:53 mid-ipa-vp01 sshd[12621]: debug1: PAM: setting PAM_TTY to 
> "ssh"
> Mar 30 08:53:53 mid-ipa-vp01 sshd[12621]: debug1: userauth-re

Re: [Freeipa-users] Troubleshooting SSO

[Sumit Bose]

:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive
> entering
> Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: monitor_read: checking
> request 100
> Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: PAM: initializing for
> "adm-faru03@test.osuwmc"
> Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: PAM: setting PAM_RHOST
> to "svr-addc-vt01.test.osuwmc"
> Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: PAM: setting PAM_TTY to
> "ssh"
> Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: monitor_read: 100 used
> once, disabling now
> Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: userauth-request for
> user adm-faru03@test.osuwmc service ssh-connection method gssapi-with-mic
> [preauth]
> Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: attempt 1 failures 0
> [preauth]
> Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: input_userauth_request:
> try method gssapi-with-mic [preauth]
> Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_send
> entering: type 42 [preauth]
> Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3:
> mm_request_receive_expect entering: type 43 [preauth]
> Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive
> entering [preauth]
> Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive
> entering
> Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: monitor_read: checking
> request 4
> Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_answer_authserv:
> service=ssh-connection, style=
> Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: monitor_read: 4 used
> once, disabling now
> Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive
> entering
> Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: monitor_read: checking
> request 80
> Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_answer_authrole: role=
> Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: monitor_read: 80 used
> once, disabling now
> Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive
> entering
> Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: monitor_read: checking
> request 42
> Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_send
> entering: type 43
> Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: Postponed gssapi-with-mic for
> adm-faru03@test.osuwmc from 10.80.5.239 port 50824 ssh2 [preauth]
> Mar 30 09:57:23 mid-ipa-vp01 sshd[12793]: debug1: userauth-request for
> user adm-faru03@test.osuwmc service ssh-connection method password
> [preauth]
> Mar 30 09:57:23 mid-ipa-vp01 sshd[12793]: debug1: attempt 2 failures 0
> [preauth]
> Mar 30 09:57:23 mid-ipa-vp01 sshd[12793]: debug2: input_userauth_request:
> try method password [preauth]
> Mar 30 09:57:23 mid-ipa-vp01 sshd[12793]: debug3: mm_auth_password
> entering [preauth]
> Mar 30 09:57:23 mid-ipa-vp01 sshd[12793]: debug3: mm_request_send
> entering: type 12 [preauth]
> Mar 30 09:57:23 mid-ipa-vp01 sshd[12793]: debug3: mm_auth_password:
> waiting for MONITOR_ANS_AUTHPASSWORD [preauth]
> Mar 30 09:57:23 mid-ipa-vp01 sshd[12793]: debug3:
> mm_request_receive_expect entering: type 13 [preauth]
> Mar 30 09:57:23 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive
> entering [preauth]
> Mar 30 09:57:23 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive
> entering
> Mar 30 09:57:23 mid-ipa-vp01 sshd[12793]: debug3: monitor_read: checking
> request 12
> Mar 30 09:57:23 mid-ipa-vp01 sshd[12793]: debug3: PAM: sshpam_passwd_conv
> called with 1 messages
> Mar 30 09:57:23 mid-ipa-vp01 sshd[12793]: pam_unix(sshd:auth):
> authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
> rhost=svr-addc-vt01.test.osuwmc  user=adm-faru03@test.osuwmc
> Mar 30 09:57:25 mid-ipa-vp01 sshd[12793]: pam_sss(sshd:auth):
> authentication success; logname= uid=0 euid=0 tty=ssh ruser=
> rhost=svr-addc-vt01.test.osuwmc user=adm-faru03@test.osuwmc
> Mar 30 09:57:25 mid-ipa-vp01 sshd[12793]: debug1: PAM: password
> authentication accepted for adm-faru03@test.osuwmc
> 
> 
> 
> On 3/30/15, 9:35 AM, "Sumit Bose"  wrote:
> 
> >assuming you have a valid Kerberos ticket the most probable reason is
> >that libkrb5 cannot properly relate the Kerberos principal from the
> >ticket to the local user name you use at the login prompt. With DEBUG3
> >you should see some messages containing '*userok*'. If you see failures
> >related to these messages it most probable is this case.
> >
> >Recent versions of SSSD will configure a plugin for libkrb5 which can
> >handle this. But for older version you either have to create a .k5login
> >file in the users home directory containing the Kerberos principal or
> >use auth_to_local directives in /etc/krb5.conf as described in
> >https://urldefense.proofpoint.com/v2/url?u=http-3A__www.freeipa.org_page_A
> >ctive-5FDirectory-5Ftrust-5Fsetup-23Edit-5F.2Fetc.2Fkrb5.conf&d=AwIDaQ&c=k
> >9MF1d71ITtkuJx-PdWme51dKbmfPEvxwt8SFEkBfs4&r=C8H0y1Bn8C6Mf5i9qrqkUDy3xSk8z
> >PbIs_SvJwojC24&m=4CkfthdUOBBXSFdkUzW4imHzEchORW-ZPDVNXQlaZ3A&s=a7-Ti-Mlcie
> >m4dhsLicRf0Qg6sZDhThV-kMNED2rYug&e=
> >
> >HTH
> >
> >bye,
> >Sumit
> 
> 

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

Re: [Freeipa-users] Troubleshooting SSO

[Sumit Bose]

On Tue, Mar 31, 2015 at 07:56:53AM +0200, Jan Cholasta wrote:
> Hi,
> 
> Dne 30.3.2015 v 19:42 Gould, Joshua napsal(a):
> >
> >On 3/30/15, 11:56 AM, "Dmitri Pal"  wrote:
> >
> >>>#  auth_to_local =
> >>>RULE:[1:$1@$0](^.*@TEST.OSUWMC$)s/@TEST.OSUWMC/@test.osuwmc/
> >>>auth_to_local = RULE:[1:$1 $0](^ *
> >>>TEST.OSUWMC$)s/@TEST.OSUWMC/@test.osuwmc/
> >>If you use the plugin then this RULE should not be needed.
> >>Have you tried commenting it out and restarting SSSD?
> >
> >I commented out those lines and restarted SSSD. I still was not able to
> >get in with SSO.
> >
> >Mar 30 13:33:35 mid-ipa-vp01 sshd[12789]: debug3: fd 5 is not O_NONBLOCK
> >Mar 30 13:33:35 mid-ipa-vp01 sshd[12789]: debug1: Forked child 13750.
> >Mar 30 13:33:35 mid-ipa-vp01 sshd[12789]: debug3: send_rexec_state:
> >entering fd = 8 config len 899
> >Mar 30 13:33:35 mid-ipa-vp01 sshd[12789]: debug3: ssh_msg_send: type 0
> >Mar 30 13:33:35 mid-ipa-vp01 sshd[12789]: debug3: send_rexec_state: done
> >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: oom_adjust_restore
> >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: Set /proc/self/oom_score_adj to 0
> >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: rexec start in 5 out 5
> >newsock 5 pipe 7 sock 8
> >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: inetd sockets after
> >dupping: 3, 3
> >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: Connection from 10.80.5.239 port
> >65333 on 10.127.26.73 port 22
> >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: Client protocol version
> >2.0; client software version PuTTY_Release_0.64
> >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: no match:
> >PuTTY_Release_0.64
> >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: Enabling compatibility
> >mode for protocol 2.0
> >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: Local version string
> >SSH-2.0-OpenSSH_6.6.1
> >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: fd 3 setting O_NONBLOCK
> >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: ssh_sandbox_init:
> >preparing rlimit sandbox
> >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: Network child is on pid
> >13751
> >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: preauth child monitor
> >started
> >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: SELinux support enabled
> >[preauth]
> >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3:
> >ssh_selinux_change_context: setting context from
> >'system_u:system_r:sshd_t:s0-s0:c0.c1023' to 'system_u:
> >system_r:sshd_net_t:s0-s0:c0.c1023' [preauth]
> >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: privsep user:group 74:74
> >[preauth]
> >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: permanently_set_uid:
> >74/74 [preauth]
> >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: list_hostkey_types:
> >ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
> >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: SSH2_MSG_KEXINIT sent
> >[preauth]
> >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: SSH2_MSG_KEXINIT
> >received [preauth]
> >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit:
> >curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha
> >2-nistp521
> >,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,di
> >ffie-hellman-group14-sha1,diffie-hellman-group1-sha1 [preauth]
> >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit:
> >ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
> >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit:
> >aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.c
> >om,aes256-
> >g...@openssh.com,chacha20-poly1...@openssh.com,aes128-cbc,3des-cbc,blowfish-
> >cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se
> >[prea
> >uth]
> >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit:
> >aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.c
> >om,aes256-
> >g...@openssh.com,chacha20-poly1...@openssh.com,aes128-cbc,3des-cbc,blowfish-
> >cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se
> >[prea
> >uth]
> >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit:
> >hmac-md5-...@openssh.com,hmac-sha1-...@openssh.com,umac-64-...@openssh.com,
> >umac-128-e
> >t...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,
> >hmac-ripemd160-...@openssh.com,hmac-sha1-96-...@openssh.com,hmac-md5-96-etm
> >@ope
> >nssh.com,hmac-md5,hmac-sha1,umac...@openssh.com,umac-...@openssh.com,hmac-s
> >ha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-9
> >6,hm
> >ac-md5-96 [preauth]
> >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit:
> >hmac-md5-...@openssh.com,hmac-sha1-...@openssh.com,umac-64-...@openssh.com,
> >umac-128-e
> >t...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,
> >hmac-ripemd160-...@openssh.com,hmac-sha1-96-...@openssh.com,hmac-md5-96-etm
> >@ope
> >nssh.com,hmac-md5,hmac-sha1,umac...@

Re: [Freeipa-users] Additional pre-authentication required, Ticket Wrong ?

[Sumit Bose]

On Tue, Mar 31, 2015 at 11:02:24AM +0200, Matt . wrote:
> On my client I still see:
> 
> 03/31/2015 11:00:08  04/01/2015 11:00:07  krbtgt/DOMAIN.LOCAL@DOMAIN.LOCAL
> 03/31/2015 11:00:09  04/01/2015 11:00:07  
> HTTP/ldap-01.domain.local@DOMAIN.LOCAL
> 
> Should ldap-01 not be ldap as I go through my loadbalancer ?

I guess not, because your loadbalancer just redirects the traffic and
the authentication is done with ldap-01.

bye,
Sumit

> 
> Do I need to merge keytabs or so ?
> 
> 2015-03-31 7:54 GMT+02:00 Matt . :
> > Hi,
> >
> > I tried to trace some stuff but this doesn't give me much more info.
> >
> > What I see at the moment in the /var/log/httpd/acces_log is exactly
> > what happens but without the info I need to get a better view:
> >
> > 10.10.0.121 - - [30/Mar/2015:22:22:58 +0200] "POST /ipa/json HTTP/1.1" 301 
> > 258
> > 10.10.0.121 - - [30/Mar/2015:22:22:58 +0200] "POST /ipa/json HTTP/1.1"
> > 301 259 "https://ldap.domain.local/ipa/json"; "-"
> > 10.10.0.121 - - [30/Mar/2015:22:22:58 +0200] "POST /ipa/json HTTP/1.1" 401 
> > 1469
> > 10.10.0.121 - - [30/Mar/2015:22:22:59 +0200] "POST /ipa/json HTTP/1.1" 401 
> > 1469
> >
> > 2015-03-30 15:03 GMT+02:00 Sumit Bose :
> >> On Mon, Mar 30, 2015 at 04:56:11AM +0200, Matt . wrote:
> >>> Hi,
> >>>
> >>> I just tot home and typing from my cell so i'm suite short in words
> >>>
> >>> Create keytab for ldap-01.domain
> >>> Kinit with that to ldap.domain
> >>> Curl against ldap.domain
> >>> Get a 301 which I manage from curl (goes well)
> >>> Get kerberos ticket error
> >>>
> >>> now I don't kinit anymore so re-use my existing ticket and curl against
> >>> ldap-01.domain and I'm accepted and can execute stuff.
> >>>
> >>> My ssl is OK, ticket also it seems.
> >>
> >> Maybe the output of
> >>
> >> KRB5_TRACE=/dev/sdtout curl -v 
> >>
> >> might help to see what is going on?
> >>
> >> bye,
> >> Sumit
> >>
> >>>
> >>> Thanks M.
> >>> Op 30 mrt. 2015 03:50 schreef "Dmitri Pal" :
> >>>
> >>> > On 03/29/2015 04:47 AM, Matt . wrote:
> >>> >
> >>> >> Hi Guys,
> >>> >>
> >>> >> Now my Certification issues are solved for using a loadbalancer in
> >>> >> front of my ipa servers I get the following:
> >>> >>
> >>> >> Unable to verify your Kerberos credentials
> >>> >>
> >>> >> and in my logs:
> >>> >>
> >>> >> Additional pre-authentication required.
> >>> >>
> >>> >> This happens when I connect throught my loadbalancers, I see my server
> >>> >> coming ni with the right IP.
> >>> >>
> >>> >> When I access my ipa server directly, not using the loadbalancer IP
> >>> >> between it, my kerberos Ticket is valid.
> >>> >>
> >>> >> I get the feeling that when I use my loadbalancers and because of that
> >>> >> I get a 301 redirect it needs a preauth. I see some issues on
> >>> >> mailinglists but it doesn't fit my situation.
> >>> >>
> >>> >> Why wants it the preauth when I already have a valid ticket and my
> >>> >> redirect is followed by CURL and posted the right way ?
> >>> >>
> >>> >
> >>> > Can you describe the sequence?
> >>> > What do you do?
> >>> >
> >>> > From the client you try IPA CLI and this is where you see the problem 
> >>> > even
> >>> > with the valid ticket or is the flow different?
> >>> >
> >>> >  I hope someone has an idea.
> >>> >>
> >>> >> Thanks,
> >>> >>
> >>> >> Matt
> >>> >>
> >>> >>
> >>> >
> >>> > --
> >>> > Thank you,
> >>> > Dmitri Pal
> >>> >
> >>> > Sr. Engineering Manager IdM portfolio
> >>> > Red Hat, Inc.
> >>> >
> >>> > --
> >>> > 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
> >>> >
> >>
> >>> --
> >>> 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
> >>

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

Re: [Freeipa-users] Additional pre-authentication required, Ticket Wrong ?

[Sumit Bose]

On Tue, Mar 31, 2015 at 11:38:30AM +0200, Matt . wrote:
> Here some extra logging from the kerberos log:
> 
> Mar 31 11:34:51 ldap-01.domain.local krb5kdc[2764](info): AS_REQ (6
> etypes {18 17 16 23 25 26}) 10.10.0.121: NEEDED_PREAUTH:
> kinituser@DOMAIN.LOCAL for krbtgt/DOMAIN.LOCAL@DOMAIN.LOCAL,
> Additional pre-authentication required
> Mar 31 11:34:51 ldap-01.domain.local krb5kdc[2764](info): AS_REQ (6
> etypes {18 17 16 23 25 26}) 10.10.0.121: ISSUE: authtime 1427794491,
> etypes {rep=18 tkt=18 ses=18}, kinituser@DOMAIN.LOCAL for
> krbtgt/DOMAIN.LOCAL@DOMAIN.LOCAL
> Mar 31 11:34:51 ldap-01.domain.local krb5kdc[2764](info): TGS_REQ (6
> etypes {18 17 16 23 25 26}) 10.10.0.121: ISSUE: authtime 1427794491,
> etypes {rep=18 tkt=18 ses=18}, kinituser@DOMAIN.LOCAL for
> HTTP/ldap-01.domain.local@DOMAIN.LOCAL
> 
> 
> I don't get the preauth needed, does it have anything todo with the
> 301 redirect which I follow with CURL ?

no, this is part of the AS_REQ (request to get a TGT) and will always
happen. Since the Kerberos client cannot know what kind of pre-auth
schemes are supported or required in the server side it first send a
request without pre-auth data. The server sends back a list of supported
schemes with a special NEEDED_PREAUTH error code if pre-auth is
required. And with IPA pre-auth is required otherwise e.g. replay
attacks would be easy.

HTH

bye,
Sumit

> 
> 2015-03-31 11:15 GMT+02:00 Matt . :
> > Yes I would assume too, but it's just kicking out possibilities what
> > could make it not working.
> >
> > I cannot figure out why it only logs the 401 after the known 301's in
> > the access_log and nothing further, apache really blocks, so kerberos
> > should be in the way for sure, but how.
> >
> >
> >
> > 2015-03-31 11:09 GMT+02:00 Sumit Bose :
> >> On Tue, Mar 31, 2015 at 11:02:24AM +0200, Matt . wrote:
> >>> On my client I still see:
> >>>
> >>> 03/31/2015 11:00:08  04/01/2015 11:00:07  krbtgt/DOMAIN.LOCAL@DOMAIN.LOCAL
> >>> 03/31/2015 11:00:09  04/01/2015 11:00:07  
> >>> HTTP/ldap-01.domain.local@DOMAIN.LOCAL
> >>>
> >>> Should ldap-01 not be ldap as I go through my loadbalancer ?
> >>
> >> I guess not, because your loadbalancer just redirects the traffic and
> >> the authentication is done with ldap-01.
> >>
> >> bye,
> >> Sumit
> >>
> >>>
> >>> Do I need to merge keytabs or so ?
> >>>
> >>> 2015-03-31 7:54 GMT+02:00 Matt . :
> >>> > Hi,
> >>> >
> >>> > I tried to trace some stuff but this doesn't give me much more info.
> >>> >
> >>> > What I see at the moment in the /var/log/httpd/acces_log is exactly
> >>> > what happens but without the info I need to get a better view:
> >>> >
> >>> > 10.10.0.121 - - [30/Mar/2015:22:22:58 +0200] "POST /ipa/json HTTP/1.1" 
> >>> > 301 258
> >>> > 10.10.0.121 - - [30/Mar/2015:22:22:58 +0200] "POST /ipa/json HTTP/1.1"
> >>> > 301 259 "https://ldap.domain.local/ipa/json"; "-"
> >>> > 10.10.0.121 - - [30/Mar/2015:22:22:58 +0200] "POST /ipa/json HTTP/1.1" 
> >>> > 401 1469
> >>> > 10.10.0.121 - - [30/Mar/2015:22:22:59 +0200] "POST /ipa/json HTTP/1.1" 
> >>> > 401 1469
> >>> >
> >>> > 2015-03-30 15:03 GMT+02:00 Sumit Bose :
> >>> >> On Mon, Mar 30, 2015 at 04:56:11AM +0200, Matt . wrote:
> >>> >>> Hi,
> >>> >>>
> >>> >>> I just tot home and typing from my cell so i'm suite short in words
> >>> >>>
> >>> >>> Create keytab for ldap-01.domain
> >>> >>> Kinit with that to ldap.domain
> >>> >>> Curl against ldap.domain
> >>> >>> Get a 301 which I manage from curl (goes well)
> >>> >>> Get kerberos ticket error
> >>> >>>
> >>> >>> now I don't kinit anymore so re-use my existing ticket and curl 
> >>> >>> against
> >>> >>> ldap-01.domain and I'm accepted and can execute stuff.
> >>> >>>
> >>> >>> My ssl is OK, ticket also it seems.
> >>> >>
> >>> >> Maybe the output of
> >>> >>
> >>> >> KRB5_TRACE=/dev/sdtout curl -v 
> >>> >>
> >>> >> might help to see w

Re: [Freeipa-users] generic failure: GSSAPI Error: Unspecified GSS failure

[Sumit Bose]

On Tue, Mar 31, 2015 at 11:26:53AM +0200, Benoit Rousselle wrote:
> hi,
> 
> I try to set the sudo password but I get a message : GSSAPI Error
> 
> What's mean this kind of message ?
> 
>  ldappasswd -Y GSSAPI -S -h my_server
> uid=sudo,cn=sysaccounts,cn=etc,dc=my_domain,dc=com
> New password:
> Re-enter new password:
> SASL/GSSAPI authentication started
> ldap_sasl_interactive_bind_s: Local error (-2)
> additional info: SASL(-1): generic failure: GSSAPI Error:
> Unspecified GSS failure.  Minor code may provide more information (Ticket
> expired)

'Ticket expired', so you either have to call kinit again to get a fresh
TGT or there is some severe time mismatch between the client and the
server.

HTH

bye,
Sumit

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

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

Re: [Freeipa-users] Troubleshooting SSO

[Sumit Bose]

On Tue, Mar 31, 2015 at 10:02:37AM -0400, Gould, Joshua wrote:
> Klist in Windows showed one ticket for the IPA domain.
> 
> #0>   Client: adm-faru03 @ test.osuwmc
>   Server: krbtgt/UNIX.TEST.OSUWMC @ TEST.OSUWMC
>   KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
>   Ticket Flags 0x40a4 -> forward able renewable pre_authent
> ok_as_delegate
>   Start Time: 3/31/2015: 9:29:25 (local)
>   End Time:   3/31/2015: 15:28:22 (local)
>   Session Key Type: AES-256-CTS-HMAC-SHA1-96

The means that you do not have a ticket for the IPA client. Please make
sure you use 'mid-ipa-vp01.unix.test.osuwmc' as hostname with putty.

Since the AD DC gave you the cross-realm TGT (the ticket you've shown
above) I would expect that you Windows client has issues resolving a KDC
in the IPA domain. Please check on the Windows client with the nslookup
utility you DNS SRV records like

_kerberos._tcp.dc._msdcs.unix.test.osuwmc

and

_kerberos._tcp.unix.test.osuwmc

can be resolved.

> 
> IPA and SSSD are:
> ipa-server.x86_64  
> 4.1.0-18.el7_1.3
> sssd.x86_64
> 1.12.2-58.el7_1.6.1
> 
> Kinit adm-faru03@TEST.OSUWMC was telling. Once it reported ³kinit: KDC
> reply did not match expectations while getting initial credentials². We
> waited a minute or two (were discussing results) and tried again just
> adding the -V flag and it worked.
> 
> Kvno host/mid-ipa-vp01.unix.test.osu...@unix.test.OSUWMC = 2
> 
> Verbose logging in putty gave the following error:
> 

Which errors do you see when using ssh in the IPA client after calling
kinit? Or is it working in this case?

bye,
Sumit

> 
> On 3/31/15, 3:30 AM, "Sumit Bose"  wrote:
> 
> >
> >Can you do the follwoing checks:
> >
> >Can you check by calling klist in a Windows Command window if you got
> >  
> >  
> >a proper host/... ticket for the IPA host?
> >  
> >  
> >  
> >  
> >  
> >What version of IPA and SSSD are you using.
> >  
> >  
> >  
> >  
> >  
> >Can you check if the following works on a IPA host:
> >  
> >  
> >  
> >  
> >  
> >kinit adm-faru03@TEST.OSUWMC
> >  
> >  
> >kvno host/name.of.the.ipa-client.to.login@IPA.REALM
> >  
> >  
> >ssh -v -l adm-faru03@test.osuwmc name.of.the.ipa-client.to.login
> >  
> >  
> 
> 

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

Re: [Freeipa-users] ipactl start fails for no apparent reason

[Sumit Bose]

On Wed, Apr 01, 2015 at 01:20:44PM +0200, Martin Babinsky wrote:
> On 04/01/2015 10:14 AM, Traiano Welcome wrote:
> >Hi Martin
> >
> >  Thanks for the response. Check results inline:
> >
> >
> >On Wed, Apr 1, 2015 at 10:37 AM, Martin Babinsky  wrote:
> >>On 04/01/2015 09:20 AM, Traiano Welcome wrote:
> >>>
> >>>Some information from the dirsrv error log (sanitized: XYZ = realm):
> >>>
> >>>[01/Apr/2015:11:01:49 +0300] - 389-Directory/1.3.1.6 B2014.160.2139
> >>>starting up
> >>>[01/Apr/2015:11:01:49 +0300] schema-compat-plugin - warning: no
> >>>entries set up under cn=computers, cn=compat,dc=idm,dc=local
> >>>[01/Apr/2015:11:01:49 +0300] - Skipping CoS Definition cn=Password
> >>>Policy,cn=accounts,dc=idm,dc=local--no CoS Templates found, which
> >>>should be added before the CoS Definition.
> >>>[01/Apr/2015:11:01:49 +0300] NSMMReplicationPlugin - CleanAllRUV Task:
> >>>cleanAllRUV task found, resuming the cleaning of rid(6)...
> >>>[01/Apr/2015:11:01:49 +0300] - Skipping CoS Definition cn=Password
> >>>Policy,cn=accounts,dc=idm,dc=local--no CoS Templates found, which
> >>>should be added before the CoS Definition.
> >>>[01/Apr/2015:11:01:49 +0300] - slapd started.  Listening on All
> >>>Interfaces port 389 for LDAP requests
> >>>[01/Apr/2015:11:01:49 +0300] - Listening on All Interfaces port 636
> >>>for LDAPS requests
> >>>[01/Apr/2015:11:01:49 +0300] - Listening on
> >>>/var/run/slapd-IDM-LOCAL.socket for LDAPI requests
> >>>[01/Apr/2015:11:01:49 +0300] set_krb5_creds - Could not get initial
> >>>credentials for principal [ldap/kwtpr-idm-mstr@] in keytab
> >>>[FILE:/etc/dirsrv/ds.keytab]: -1765328203 (Key table entry not found)
> >>>[01/Apr/2015:11:01:49 +0300] set_krb5_creds - Could not get initial
> >>>credentials for principal [ldap/kwtpr-idm-mstr@] in keytab
> >>>[FILE:/etc/dirsrv/ds.keytab]: -1765328203 (Key table entry not found)
> >>>[01/Apr/2015:11:01:49 +0300] set_krb5_creds - Could not get initial
> >>>credentials for principal [ldap/kwtpr-idm-mstr@] in keytab
> >>>[FILE:/etc/dirsrv/ds.keytab]: -1765328203 (Key table entry not found)
> >>>[01/Apr/2015:11:01:49 +0300] set_krb5_creds - Could not get initial
> >>>credentials for principal [ldap/kwtpr-idm-mstr@] in keytab
> >>>[FILE:/etc/dirsrv/ds.keytab]: -1765328203 (Key table entry not found)
> >>>[01/Apr/2015:11:01:49 +0300] set_krb5_creds - Could not get initial
> >>>credentials for principal [ldap/kwtpr-idm-mstr@] in keytab
> >>>[FILE:/etc/dirsrv/ds.keytab]: -1765328203 (Key table entry not found)
> >>>[01/Apr/2015:11:01:49 +0300] slapd_ldap_sasl_interactive_bind - Error:
> >>>could not perform interactive bind for id [] mech [GSSAPI]: LDAP error
> >>>-2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified
> >>>GSS failure.  Minor code may provide more information (No Kerberos
> >>>credentials available)) errno 0 (Success)
> >>>[01/Apr/2015:11:01:49 +0300] slapi_ldap_bind - Error: could not
> >>>perform interactive bind for id [] authentication mechanism [GSSAPI]:
> >>>error -2 (Local error)
> >>>[01/Apr/2015:11:01:49 +0300] NSMMReplicationPlugin -
> >>>agmt="cn=meTokwtard-idm-slve.idm.local" (kwtard-idm-slve:389):
> >>>Replication bind with GSSAPI auth failed: LDAP error -2 (Local error)
> >>>(SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.
> >>>Minor code may provide more information (No Kerberos credentials
> >>>available))
> >>>[01/Apr/2015:11:01:49 +0300] slapd_ldap_sasl_interactive_bind - Error:
> >>>could not perform interactive bind for id [] mech [GSSAPI]: LDAP error
> >>>-2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified
> >>>GSS failure.  Minor code may provide more information (No Kerberos
> >>>credentials available)) errno 0 (Success)
> >>>[01/Apr/2015:11:01:49 +0300] slapi_ldap_bind - Error: could not
> >>>perform interactive bind for id [] authentication mechanism [GSSAPI]:
> >>>error -2 (Local error)
> >>>[01/Apr/2015:11:01:49 +0300] NSMMReplicationPlugin -
> >>>agmt="cn=meToindpr-idm-slve.idm.local" (indpr-idm-slve:389):
> >>>Replication bind with GSSAPI auth failed: LDAP error -2 (Local error)
> >>>(SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.
> >>>Minor code may provide more information (No Kerberos credentials
> >>>available))
> >>>[01/Apr/2015:11:01:50 +0300] - slapd shutting down - signaling operation
> >>>threads
> >>>[01/Apr/2015:11:01:50 +0300] - slapd shutting down - waiting for 27
> >>>threads to terminate
> >>>[01/Apr/2015:11:01:50 +0300] - slapd shutting down - closing down
> >>>internal subsystems and plugins
> >>>[01/Apr/2015:11:01:58 +0300] NSMMReplicationPlugin - CleanAllRUV Task:
> >>>Cleaning rid (6)...
> >>>[01/Apr/2015:11:01:58 +0300] NSMMReplicationPlugin - CleanAllRUV Task:
> >>>Waiting to process all the updates from the deleted replica...
> >>>[01/Apr/2015:11:01:58 +0300] NSMMReplicationPlugin - CleanAllRUV Task:
> >>>Waiting for all the replicas to be online...
> >>>[01/Apr/2015:11:01:58 +0300] NSMMReplicationPlugin - CleanAl

Re: [Freeipa-users] posix ids not propgating

[Sumit Bose]

On Thu, Apr 16, 2015 at 07:46:55PM -0400, Bryan Pearson wrote:
> I ran this comand on each of my IPA servers and one returned usable
> response: ipa idrange-find
> 
> ---
> 1 range matched
> ---
>   Range name: HOSTNAME.LAN_id_range
>   First Posix ID of the range: 192020
>   Number of IDs in the range: 30
>   Range type: local domain range
> 
> Number of entries returned 1
> 
> 
> While trying to add a new user on one of the other severs I recieve:
> ***
> Operations error: Allocation of a new value for range cn=posix
> ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config
> failed! Unable to proceed.
> ***

This is expected, unfortunately the idranges used to manage different
idranges in environments with trust and the range used by the DNA plugin
to assign IDs to local users and groups are currently not connected.
There is ticket https://fedorahosted.org/freeipa/ticket/3609 to fix
this.

bye,
Sumit

> 
> Should I go forward on other masters and do:
> 
> ***
> ldapmodify -x -D 'cn=Directory Manager' -W
> Enter LDAP Password:
> dn: cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config
> changetype: modify
> replace: dnaNextValue
> dnaNextValue: 168970
> -
> replace: dnaMaxValue
> dnaMaxValue: 168979
> ^D
> 
> modifying entry "cn=Posix IDs,cn=Distributed Numeric Assignment
> Plugin,cn=plugins,cn=config"
> ***
> 
> -- 
> 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

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

Re: [Freeipa-users] posix ids not propgating

[Sumit Bose]

On Fri, Apr 17, 2015 at 06:36:24AM -0400, Bryan Pearson wrote:
> Should I add the same range to this machine or give each one it's own id
> range?

The ranges are global for the whole IPA domain. The idranges manages
with the ipa tool have their data in the replicated tree hence changes
are available on all replicas. The DNA plugin has its own scheme to
distribute the data, see e.g.

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/Managing-Unique_UID_and_GID_Attributes.html

for details.

bye,
Sumit
> On Apr 17, 2015 3:53 AM, "Sumit Bose"  wrote:
> 
> > On Thu, Apr 16, 2015 at 07:46:55PM -0400, Bryan Pearson wrote:
> > > I ran this comand on each of my IPA servers and one returned usable
> > > response: ipa idrange-find
> > >
> > > ---
> > > 1 range matched
> > > ---
> > >   Range name: HOSTNAME.LAN_id_range
> > >   First Posix ID of the range: 192020
> > >   Number of IDs in the range: 30
> > >   Range type: local domain range
> > > 
> > > Number of entries returned 1
> > > 
> > >
> > > While trying to add a new user on one of the other severs I recieve:
> > > ***
> > > Operations error: Allocation of a new value for range cn=posix
> > > ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config
> > > failed! Unable to proceed.
> > > ***
> >
> > This is expected, unfortunately the idranges used to manage different
> > idranges in environments with trust and the range used by the DNA plugin
> > to assign IDs to local users and groups are currently not connected.
> > There is ticket https://fedorahosted.org/freeipa/ticket/3609 to fix
> > this.
> >
> > bye,
> > Sumit
> >
> > >
> > > Should I go forward on other masters and do:
> > >
> > > ***
> > > ldapmodify -x -D 'cn=Directory Manager' -W
> > > Enter LDAP Password:
> > > dn: cn=Posix IDs,cn=Distributed Numeric Assignment
> > Plugin,cn=plugins,cn=config
> > > changetype: modify
> > > replace: dnaNextValue
> > > dnaNextValue: 168970
> > > -
> > > replace: dnaMaxValue
> > > dnaMaxValue: 168979
> > > ^D
> > >
> > > modifying entry "cn=Posix IDs,cn=Distributed Numeric Assignment
> > > Plugin,cn=plugins,cn=config"
> > > ***
> > >
> > > --
> > > 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
> >

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

Re: [Freeipa-users] LDAP bind failing on new IPA setup

[Sumit Bose]

On Fri, Apr 17, 2015 at 10:29:31AM -0400, Gould, Joshua wrote:
> We setup our new IPA server (RHEL7) with a trust against our AD domain. The 
> trust and ID range look right in IPA
> 
> [root sssd]# ipa trust-show
> Realm name: example.com
>   Realm name: EXAMPLE.COM
>   Domain NetBIOS name: EXAMPLE
>   Domain Security Identifier: S-1-5-21-
>   Trust direction: Two-way trust
>   Trust type: Active Directory domain
> [root sssd]# ipa idrange-find --all
> 
> 2 ranges matched
> 
>   dn: cn=EXAMPLE.COM_id_range,cn=ranges,cn=etc,dc=examle,dc=com
>   Range name: EXAMPLE.COM_id_range
>   First Posix ID of the range: 200
>   Number of IDs in the range: 90
>   First RID of the corresponding RID range: 0
>   Domain SID of the trusted domain: S-1-5-21-
>   Range type: Active Directory domain range
>   iparangetyperaw: ipa-ad-trust
>   objectclass: ipatrustedaddomainrange, ipaIDrange
> 
>   dn: cn=UNIX.EXAMPLE.COM_id_range,cn=ranges,cn=etc,dc=example,dc=com
>   Range name: UNIX.EXAMPLE.COM_id_range
>   First Posix ID of the range: 36960
>   Number of IDs in the range: 20
>   First RID of the corresponding RID range: 1000
>   First RID of the secondary RID range: 1
>   Range type: local domain range
>   iparangetyperaw: ipa-local
>   objectclass: top, ipaIDrange, ipaDomainIDRange
> 
> Number of entries returned 2
> 
> [root sssd]#
> 
> I see that the bind fails but I’m not sure why. Here are the errors. Could 
> someone point me in the right direction please?
> 
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] 
> [sdap_get_server_opts_from_rootdse] (0x0100): Setting AD compatibility level 
> to [4]
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [sdap_kinit_send] 
> (0x0400): Attempting kinit (default, host/xxx, UNIX.EXAMPLE.COM, 86400)
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [sdap_kinit_next_kdc] 
> (0x1000): Resolving next KDC for service EXAMPLE.COM
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] 
> [fo_resolve_service_send] (0x0100): Trying to resolve service 'EXAMPLE.COM'
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [get_server_status] 
> (0x1000): Status of server 'domain_controller.EXAMPLE.COM' is 'name resolved'
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] 
> [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 
> seconds
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [resolve_srv_send] 
> (0x0200): The status of SRV lookup is resolved
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [get_server_status] 
> (0x1000): Status of server 'domain_controller.EXAMPLE.COM' is 'name resolved'
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] 
> [be_resolve_server_process] (0x1000): Saving the first resolved server
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] 
> [be_resolve_server_process] (0x0200): Found address for server 
> domain_controller.EXAMPLE.COM: [1.2.3.4] TTL 3600
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] 
> [sdap_kinit_kdc_resolved] (0x1000): KDC resolved, attempting to get TGT...
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] 
> [create_tgt_req_send_buffer] (0x0400): buffer size: 70
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [child_handler_setup] 
> (0x2000): Setting up signal handler up for pid [8734]
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [child_handler_setup] 
> (0x2000): Signal handler set up for pid [8734]
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] 
> [set_tgt_child_timeout] (0x0400): Setting 6 seconds timeout for tgt child
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [sdap_process_result] 
> (0x2000): Trace: sh[0x7f6ca7b71b70], connected[1], ops[(nil)], 
> ldap[0x7f6ca7b89f20]
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [sdap_process_result] 
> (0x2000): Trace: ldap_result found nothing!
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [write_pipe_handler] 
> (0x0400): All data has been sent!
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [child_sig_handler] 
> (0x1000): Waiting for child [8734].
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [child_sig_handler] 
> (0x0100): child [8734] finished successfully.
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [read_pipe_handler] 
> (0x0400): EOF received, client finished
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [sdap_get_tgt_recv] 
> (0x0400): Child responded: 0 [FILE:/var/lib/sss/db/ccache_UNIX.EXAMPLE.COM], 
> expired on [1429366284]
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [sdap_cli_auth_step] 
> (0x0100): expire timeout is 900
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [sdap_cli_auth_step] 
> (0x1000): the connection will expire at 1429280784
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [sasl_bind_send] 
> 

Re: [Freeipa-users] Cannot find KDC for realm "MYDOMAIN.NET" - AD trust and UPN issues

[Sumit Bose]

On Tue, May 05, 2015 at 09:09:51AM -0700, nat...@nathanpeters.com wrote:
> I am having some strange issues after upgrade from FreeIPA 4.1.2 to
> 4.1.3/4.1.4 on CentOS 7.
> 
> Here is my setup:
> FreeIPA domain : ipadomain.net
> Trusted AD domain : sub.addomain.net
> 
> In my AD domain, we have our UPN set to addomain.net so users typically
> login as usern...@addomain.net instead of usern...@sub.addomain.net.
> 
> In my /etc/sssd/sssd.conf on the ipa dc I have the following values set:
> use_fully_qualified_names = True
> [sssd]
> default_domain_suffix = sub.addomain.net
> 
> 
> This is what I see in the logs when I attempt to login as 'username' (with
> do domain):
> 
> May 05 15:36:51 ipadc1.ipadomain.net [sssd[krb5_child[4376]]][4376]:
> Cannot find KDC for realm "ADDOMAIN.NET"
> May 05 15:36:51 ipadc1.ipadomain.net [sssd[krb5_child[4376]]][4376]:
> Cannot find KDC for realm "ADDOMAIN.NET"
> May 05 15:36:51 ipadc1.ipadomain.net sshd[4373]: pam_sss(sshd:auth):
> authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
> rhost=10.5.5.57 user=username
> May 05 15:36:51 ipadc1.ipadomain.net sshd[4373]: pam_sss(sshd:auth):
> received for user username: 4 (System error)
> May 05 15:36:53 ipadc1.ipadomain.net sshd[4373]: Failed password for
> username from 10.5.5.57 port 53118 ssh2
> 
> However, if in AD I switch the UPN on 'username' to the default of
> 'sub.addomain.net' I get a successful login:
> 
> May 04 23:10:57 ipadc1.ipadomain.net sshd[2293]: pam_unix(sshd:auth):
> authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
> rhost=10.5.5.57  user=username
> May 04 23:10:58 ipadc1.ipadomain.net sshd[2293]: pam_sss(sshd:auth):
> authentication success; logname= uid=0 euid=0 tty=ssh ruser=
> rhost=10.5.5.57 user=username
> May 04 23:11:01 ipadc1.ipadomain.net sshd[2293]: Accepted password for
> username from 10.5.5.57 port 46077 ssh2
> May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Starting
> user-1539201103.slice.
> May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Created slice
> user-1539201103.slice.
> May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Starting Session 3 of
> user usern...@sub.addomain.net.
> May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Started Session 3 of user
> usern...@sub.addomain.net.
> May 04 23:11:01 ipadc1.ipadomain.net systemd-logind[716]: New session 3 of
> user usern...@sub.addomain.net.
> May 04 23:11:02 ipadc1.ipadomain.net sshd[2293]: pam_unix(sshd:session):
> session opened for user username by (uid=0)
> 
> As a temporary workaround I set dns_lookup_kdc = false in my
> /etc/krb5.conf file and that worked to allow me to login with just
> 'username' but even after a successful login, I was seeing those 'cannot
> find KDC for realm' message in the log.
> 
> Is there a proper way to allow people from a trusted AD domain to login
> with their alternative UPNs?

I'm afraid currently the only way doing this is by adding a ADDOMAIN.NET
section to the realms section of /etc/krb5.conf to all IPA clients and
servers.

Although SSSD as a client in a AD domain can handle those UPNs there is
a missing part on the FreeIPA server side which is needed to make it
work. The item is tracked in
https://fedorahosted.org/freeipa/ticket/3559 .

Since the UPN-suffix can be freely chosen, i.e. it does not have to be a
DNS domain, the client will ask it's local KDC with a special so called
enterprise principal if it knows about this UPN suffix and if the KDC
knows about it it will tell the client where to ask for it. IF ticket
#3559 gets implemented the entry in /etc/krb5.conf would not be needed
anymore.

HTH

bye,
Sumit

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

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

Re: [Freeipa-users] Cannot find KDC for realm "MYDOMAIN.NET" - AD trust and UPN issues

[Sumit Bose]

On Tue, May 05, 2015 at 09:53:38AM -0700, nat...@nathanpeters.com wrote:
> Hmm, so if this is the [realms] section of my /etc/krb5.conf what do I
> have to do ?
> 
> [realms]
>  IPADOMAIN.NET = {
>   kdc = dc1.ipadomain.net:88
>   master_kdc = dc1.ipadomain.net:88
>   admin_server = dc1.ipadomain.net:749
>   default_domain = ipadomain.net
>   pkinit_anchors = FILE:/etc/ipa/ca.crt
>   auth_to_local =
> RULE:[1:$1@$0](^.*@SUB.ADDOMAIN.NET$)s/@SUB.ADDOMAIN.NET/@sub.addomain.net/
>   auth_to_local = DEFAULT
> }
> 
> Would I just literally copy that section and change the names?
> eg:
> 
>  SUB.ADDOMAIN.NET = {
>   kdc = dc1.ipadomain.net:88
>   master_kdc = dc1.ipadomain.net:88
>   admin_server = dc1.ipadomain.net:749
>   default_domain = ipadomain.net

you should add the AD DC and AD realm here

The following lines you can just drop.

HTH

bye,
Sumit

>   pkinit_anchors = FILE:/etc/ipa/ca.crt
>   auth_to_local =
> RULE:[1:$1@$0](^.*@SUB.ADDOMAIN.NET$)s/@SUB.ADDOMAIN.NET/@sub.addomain.net/
>   auth_to_local = DEFAULT
> }
> 
> 
> > On Tue, May 05, 2015 at 09:09:51AM -0700, nat...@nathanpeters.com wrote:
> >> I am having some strange issues after upgrade from FreeIPA 4.1.2 to
> >> 4.1.3/4.1.4 on CentOS 7.
> >>
> >> Here is my setup:
> >> FreeIPA domain : ipadomain.net
> >> Trusted AD domain : sub.addomain.net
> >>
> >> In my AD domain, we have our UPN set to addomain.net so users typically
> >> login as usern...@addomain.net instead of usern...@sub.addomain.net.
> >>
> >> In my /etc/sssd/sssd.conf on the ipa dc I have the following values set:
> >> use_fully_qualified_names = True
> >> [sssd]
> >> default_domain_suffix = sub.addomain.net
> >>
> >>
> >> This is what I see in the logs when I attempt to login as 'username'
> >> (with
> >> do domain):
> >>
> >> May 05 15:36:51 ipadc1.ipadomain.net [sssd[krb5_child[4376]]][4376]:
> >> Cannot find KDC for realm "ADDOMAIN.NET"
> >> May 05 15:36:51 ipadc1.ipadomain.net [sssd[krb5_child[4376]]][4376]:
> >> Cannot find KDC for realm "ADDOMAIN.NET"
> >> May 05 15:36:51 ipadc1.ipadomain.net sshd[4373]: pam_sss(sshd:auth):
> >> authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
> >> rhost=10.5.5.57 user=username
> >> May 05 15:36:51 ipadc1.ipadomain.net sshd[4373]: pam_sss(sshd:auth):
> >> received for user username: 4 (System error)
> >> May 05 15:36:53 ipadc1.ipadomain.net sshd[4373]: Failed password for
> >> username from 10.5.5.57 port 53118 ssh2
> >>
> >> However, if in AD I switch the UPN on 'username' to the default of
> >> 'sub.addomain.net' I get a successful login:
> >>
> >> May 04 23:10:57 ipadc1.ipadomain.net sshd[2293]: pam_unix(sshd:auth):
> >> authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
> >> rhost=10.5.5.57  user=username
> >> May 04 23:10:58 ipadc1.ipadomain.net sshd[2293]: pam_sss(sshd:auth):
> >> authentication success; logname= uid=0 euid=0 tty=ssh ruser=
> >> rhost=10.5.5.57 user=username
> >> May 04 23:11:01 ipadc1.ipadomain.net sshd[2293]: Accepted password for
> >> username from 10.5.5.57 port 46077 ssh2
> >> May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Starting
> >> user-1539201103.slice.
> >> May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Created slice
> >> user-1539201103.slice.
> >> May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Starting Session 3 of
> >> user usern...@sub.addomain.net.
> >> May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Started Session 3 of
> >> user
> >> usern...@sub.addomain.net.
> >> May 04 23:11:01 ipadc1.ipadomain.net systemd-logind[716]: New session 3
> >> of
> >> user usern...@sub.addomain.net.
> >> May 04 23:11:02 ipadc1.ipadomain.net sshd[2293]: pam_unix(sshd:session):
> >> session opened for user username by (uid=0)
> >>
> >> As a temporary workaround I set dns_lookup_kdc = false in my
> >> /etc/krb5.conf file and that worked to allow me to login with just
> >> 'username' but even after a successful login, I was seeing those 'cannot
> >> find KDC for realm' message in the log.
> >>
> >> Is there a proper way to allow people from a trusted AD domain to login
> >> with their alternative UPNs?
> >
> > I'm afraid currently the only way doing this is by adding a ADDOMAIN.NET
> > section to the realms section of /etc/krb5.conf to all IPA clients and
> > servers.
> >
> > Although SSSD as a client in a AD domain can handle those UPNs there is
> > a missing part on the FreeIPA server side which is needed to make it
> > work. The item is tracked in
> > https://fedorahosted.org/freeipa/ticket/3559 .
> >
> > Since the UPN-suffix can be freely chosen, i.e. it does not have to be a
> > DNS domain, the client will ask it's local KDC with a special so called
> > enterprise principal if it knows about this UPN suffix and if the KDC
> > knows about it it will tell the client where to ask for it. IF ticket
> > #3559 gets implemented the entry in /etc/krb5.conf would not be needed
> > anymore.
> >
> > HTH
> >
> > bye,
> > Sumit
> >
> >>
> >>
> >> --
> >> Manage your subscription for the Freeipa-users mai

Re: [Freeipa-users] Cannot find KDC for realm "MYDOMAIN.NET" - AD trust and UPN issues

[Sumit Bose]

On Tue, May 05, 2015 at 09:14:52PM -0700, Nathan Peters wrote:
> >From this link  :
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/active-directory-trust.html#comp-trust-krb
> 
> The diagram in that section shows the client communicating with FreeIPA and
> FreeIPA contacting AD.
> 
> So why are you saying the client authenticates with the AD DC directly?

If you want to look up user data like e.g. the UID  or the home
directory the IPA client will talk to the IPA server exclusively, if the
server does not know about the requested AD user it will try to get this
information from a AD DC.

For authentication this is different, because only the AD DC should know
the password of the user. Hence authentication ans password changes as
well are done directly with the AD DC.

> 
> Also this page here :
> https://www.freeipa.org/page/Active_Directory_trust_setup
> 
> does not list having to add the AD domain in the krb5.conf.  Is that not
> necessary in the example because they are not using a different UPN for
> their users like we are?

yes, it is because of the UPN in your case. As I said before this
special entry in krb5.conf would not be needed anymore if the IPA KDC
supports the Kerberos client referrals for the trusted domains. Adding
the entry to krb5.conf in only a work-around here.

bye,
Sumit

> 
> -Original Message- From: Jakub Hrozek
> Sent: Tuesday, May 05, 2015 8:43 PM
> To: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] Cannot find KDC for realm "MYDOMAIN.NET" - AD
> trust and UPN issues
> 
> On Tue, May 05, 2015 at 02:21:40PM -0700, nat...@nathanpeters.com wrote:
> >I'm a little confused by that.
> >
> >If I add the AD dc, will my client try to contact AD directly to get a
> >ticket?
> >
> >Doesn't it have to do get the ticket through FreeIPA by proxy somehow?
> 
> No, authentication is always performed against an AD DC directly.
> 
> >
> >And to confirm what you meant by add the AD dc and realm, it would be like
> >this ?
> >
> >SUB.ADDOMAIN.NET = {
> > kdc = dc1.addomain.net:88
> >}
> >
> >I don't need the master_kdc, admin_server, default_domain entries?
> 
> With a recent version of libkrb5 I don't think you need to set
> master_kdc, libkrb5 should be able to follow referrals itself.
> admin_servre, if unset, defaults to KDC. default_domain doesn't need to
> be set either.
> 
> -- 
> 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
> 
> -- 
> 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

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

Re: [Freeipa-users] Cannot find KDC for realm "MYDOMAIN.NET" - AD trust and UPN issues

[Sumit Bose]

On Wed, May 06, 2015 at 11:15:15AM -0700, nat...@nathanpeters.com wrote:
> Ok, I have attempted to set this up by adding the AD domain to my
> configuration and it still isn't working.
> I just want to confirm what I'm trying to accomplish here before I list
> what I've done to troubleshoot this.
> 
> We have an AD domain called corp.addomain.net.  We have UPNs set so AD
> users login to the AD domain as adusern...@addomain.net when they login to
> windows machines.
> 
> The linux clients in our network are currently just using straight up
> kerberos authentication against the domain and can currently login as
> 'username' without entering any suffix.
> 
> Because this means we can't control sudo policies centrally by our current
> direct kerberos connection, we want to switch to logging in through
> FreeIPA.
> I need to be clear that we want to maintain the current logins of just
> 'username' on Linux servers.
> 
> To accomplish this, I added the following line to the sssd.conf file:
> default_domain_suffix = corp.addomain.net
> 
> I have tried 3 different combinations of kerberos config to try to get the
> logins to work, but am running into errors in each case.  I have tried to
> follow the suggestions given earlier in this thread.  Here are the 3
> krb.conf configurations I tried and the errors given on each try.
> 
> -- configuration 1 ---
> 
> [realms]
>  IPADOMAIN.NET = {
>   kdc = dc1.ipadomain.net:88
>   master_kdc = dc1.ipadomain.net:88
>   admin_server = dc1.ipadomain.net:749
>   default_domain = ipadomain.net
>   pkinit_anchors = FILE:/etc/ipa/ca.crt
>   auth_to_local =
> RULE:[1:$1@$0](^.*@CORP.ADDOMAIN.NET$)s/@CORP.ADDOMAIN.NET/@corp.addomain.net/
>   auth_to_local = DEFAULT
> }
> CORP.ADDOMAIN.NET = {
>   kdc = dc3.corp.addomain.net:88
>   master_kdc = dc3.corp.addomain.net:88
> }
> 
> [domain_realm]
>  .ipadomain.net = IPADOMAIN.NET
>  ipadomain.net = IPADOMAIN.NET
>  .corp.addomain.net = CORP.ADDOMAIN.NET
>  corp.addomain.net = CORP.ADDOMAIN.NET
> 
> 
> May 06 16:43:53 dc1.ipadomain.net [sssd[krb5_child[7512]]][7512]: Cannot
> find KDC for realm "ADDOMAIN.NET"
> May 06 16:43:53 dc1.ipadomain.net [sssd[krb5_child[7512]]][7512]: Cannot
> find KDC for realm "ADDOMAIN.NET"
> May 06 16:43:53 dc1.ipadomain.net sshd[7508]: pam_sss(sshd:auth):
> authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
> rhost=10.5.5.57 user=adusername
> May 06 16:43:53 dc1.ipadomain.net sshd[7508]: pam_sss(sshd:auth): received
> for user adusername: 4 (System error)
> May 06 16:43:55 dc1.ipadomain.net sshd[7508]: Failed password for
> adusername from 10.5.5.57 port 1832 ssh2
> 
> --- configuration 2 
> 
> Notes : since the above error seemed to imply that I needed to add the
> 'UPN realm' to the [realms] section I tried to add it.
> 
> [realms]
>  IPADOMAIN.NET = {
>   kdc = dc1.ipadomain.net:88
>   master_kdc = dc1.ipadomain.net:88
>   admin_server = dc1.ipadomain.net:749
>   default_domain = ipadomain.net
>   pkinit_anchors = FILE:/etc/ipa/ca.crt
>   auth_to_local =
> RULE:[1:$1@$0](^.*@CORP.ADDOMAIN.NET$)s/@CORP.ADDOMAIN.NET/@corp.addomain.net/
>   auth_to_local = DEFAULT
> 
> }
>  ADDOMAIN.NET = {
>   kdc = dc3.corp.addomain.net:88
>   master_kdc = dc3.corp.addomain.net:88
> }
> 
> [domain_realm]
>  .ipadomain.net = IPADOMAIN.NET
>  ipadomain.net = IPADOMAIN.NET
>  addomain.net = ADDOMAIN.NET
>  .addomain.net = ADDOMAIN.NET
> 
> May 06 16:48:32 dc1.ipadomain.net [sssd[krb5_child[7546]]][7546]: Realm
> not local to KDC
> May 06 16:48:32 dc1.ipadomain.net [sssd[krb5_child[7546]]][7546]: Realm
> not local to KDC

hm, the AD DC requires that enterprise principal are used here, but we
cannot enable them because as mentioned earlier the FreeIPA KDC
currently does not support client referrals.

Basically you are seeing the same as described in
https://bugzilla.redhat.com/show_bug.cgi?id=1211631 . The
userPrincipalName attribute in AD contains a value we currently cannot
use. Unfortunately SSSD prefers this value if available and as described
in the bugzilla tickets it is currently not possible to override the
attribute name as well.

There might be one ugly hack which might help you, but it is really ugly
because you have to edit a executable file. The name of the attribute
'userPrincipalName' can be found exactly once in the IPA provider
executable, you can check this with

 strings /usr/{lib|lib64}/sssd/libsss_ipa.so | grep userPrincipalName

if you replace a single letter in this string with a different one, e.g.
'userPrinXipalName' in this file on all of your IPA servers and flush
the cache on all servers with 'sss_cache -E' and restart sssd on the
servers then SSSD should not be able anymore to read the attribute from
AD and will generate a principal on its own based on the user name and
the domain name which is corp.addomain.net in your case. With the
principal it should be possible to authenticate against AD. But as said,
this is really ugly, not supporte

Re: [Freeipa-users] HBAC rules don't work with PAM - problem

[Sumit Bose]

On Mon, May 11, 2015 at 04:47:01PM +0200, Lukas Slebodnik wrote:
> On (11/05/15 14:57), Vangass wrote:
> >Hi,
> >
> >I try to access Cisco switch via ssh. Cisco has tacacs login configured.
> >
> ># tail /var/log/secure
> >May 11 14:18:46 freeipa tac_plus[29096]: pam_sss(tac_plus:auth):
> >authentication success; logname=bartosz uid=0 euid=0 tty= ruser= rhost=
> >user=bartosz
> >May 11 14:18:53 freeipa tac_plus[29096]: pam_sss(tac_plus:auth):
> >authentication success; logname=bartosz uid=0 euid=0 tty= ruser= rhost=
> >user=test
> >
> >User bartosz is added in HBAC rule as Specified Users and Groups.
> >User test exist in FreeIPA but isn't in HBAC rule and shouldn't be
> >autheniticated.
> >
> ># cat /etc/sssd/sssd.conf
> >[domain/test.example.com]
> >debug_level = 6
> >cache_credentials = True
> >krb5_store_password_if_offline = True
> >ipa_domain = test.example.com
> >id_provider = ipa
> >auth_provider = ipa
> >access_provider = ipa
> >ipa_hostname = freeipa.test.example.com
> >chpass_provider = ipa
> >ipa_server = freeipa.test.example.com
> >ipa_server_mode = True
> >ldap_tls_cacert = /etc/ipa/ca.crt
> >
> >[sssd]
> >services = nss, sudo, pam, ssh
> >config_file_version = 2
> >domains = test.example.com
> >
> >[nss]
> >homedir_substring = /home
> >
> >[pam]
> >debug_level = 6
> >domains = test.example.com
> >
> >[sudo]
> >
> >[autofs]
> >
> >[ssh]
> >
> >[pac]
> >
> >[ifp]
> >
> >
> >#cat /var/log/sssd/sssd_pam.log
> >(Mon May 11 14:40:28 2015) [sssd[pam]] [accept_fd_handler] (0x0400): Client
> >connected to privileged pipe!
> >(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_cmd_get_version] (0x0200):
> >Received client version [3].
> >(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_cmd_get_version] (0x0200):
> >Offered version [3].
> >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_cmd_authenticate] (0x0100):
> >entering pam_cmd_authenticate
> >(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_parse_name_for_domains]
> >(0x0200): name 'test' matched without domain, user is test
> >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): command:
> >PAM_AUTHENTICATE
> >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): domain:
> >not set
> >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): user: test
> >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): service:
> >tac_plus
> >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: not
> >set
> >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser:
> >not set
> >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost:
> >not set
> >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok
> >type: 1
> >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100):
> >newauthtok type: 0
> >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 1
> >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid:
> >29218
> >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): logon
> >name: test
> >(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_dp_issue_request] (0x0400):
> >Issuing request for [0x7f4f20215ed0:3:t...@test.example.com]
> >(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_dp_get_account_msg] (0x0400):
> >Creating request for [test.example.com][3][1][name=test]
> >(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_dp_internal_get_send] (0x0400):
> >Entering request [0x7f4f20215ed0:3:t...@test.example.com]
> >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_check_user_search] (0x0100):
> >Requesting info for [t...@test.example.com]
> >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_check_user_search] (0x0400):
> >Returning info for user [t...@test.example.com]
> >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending
> >request with the following data:
> >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): command:
> >PAM_AUTHENTICATE
> >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): domain:
> >test.example.com
> >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): user: test
> >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): service:
> >tac_plus
> >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: not
> >set
> >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser:
> >not set
> >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost:
> >not set
> >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok
> >type: 1
> >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100):
> >newauthtok type: 0
> >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 1
> >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid:
> >29218
> >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): logon
> >name: test
> >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_dom_forwarder] (0x0100):
> >pam_dp_send_req returned 0
> >(Mon May 11 

Re: [Freeipa-users] HBAC rules don't work with PAM - problem

[Sumit Bose]

On Mon, May 11, 2015 at 05:15:31PM +0200, Sumit Bose wrote:
> On Mon, May 11, 2015 at 04:47:01PM +0200, Lukas Slebodnik wrote:
> > On (11/05/15 14:57), Vangass wrote:
> > >Hi,
> > >
> > >I try to access Cisco switch via ssh. Cisco has tacacs login configured.
> > >
> > ># tail /var/log/secure
> > >May 11 14:18:46 freeipa tac_plus[29096]: pam_sss(tac_plus:auth):
> > >authentication success; logname=bartosz uid=0 euid=0 tty= ruser= rhost=
> > >user=bartosz
> > >May 11 14:18:53 freeipa tac_plus[29096]: pam_sss(tac_plus:auth):
> > >authentication success; logname=bartosz uid=0 euid=0 tty= ruser= rhost=
> > >user=test
> > >
> > >User bartosz is added in HBAC rule as Specified Users and Groups.
> > >User test exist in FreeIPA but isn't in HBAC rule and shouldn't be
> > >autheniticated.
> > >
> > ># cat /etc/sssd/sssd.conf
> > >[domain/test.example.com]
> > >debug_level = 6
> > >cache_credentials = True
> > >krb5_store_password_if_offline = True
> > >ipa_domain = test.example.com
> > >id_provider = ipa
> > >auth_provider = ipa
> > >access_provider = ipa
> > >ipa_hostname = freeipa.test.example.com
> > >chpass_provider = ipa
> > >ipa_server = freeipa.test.example.com
> > >ipa_server_mode = True
> > >ldap_tls_cacert = /etc/ipa/ca.crt
> > >
> > >[sssd]
> > >services = nss, sudo, pam, ssh
> > >config_file_version = 2
> > >domains = test.example.com
> > >
> > >[nss]
> > >homedir_substring = /home
> > >
> > >[pam]
> > >debug_level = 6
> > >domains = test.example.com
> > >
> > >[sudo]
> > >
> > >[autofs]
> > >
> > >[ssh]
> > >
> > >[pac]
> > >
> > >[ifp]
> > >
> > >
> > >#cat /var/log/sssd/sssd_pam.log
> > >(Mon May 11 14:40:28 2015) [sssd[pam]] [accept_fd_handler] (0x0400): Client
> > >connected to privileged pipe!
> > >(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_cmd_get_version] (0x0200):
> > >Received client version [3].
> > >(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_cmd_get_version] (0x0200):
> > >Offered version [3].
> > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_cmd_authenticate] (0x0100):
> > >entering pam_cmd_authenticate
> > >(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_parse_name_for_domains]
> > >(0x0200): name 'test' matched without domain, user is test
> > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): command:
> > >PAM_AUTHENTICATE
> > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): domain:
> > >not set
> > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): user: 
> > >test
> > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): service:
> > >tac_plus
> > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: not
> > >set
> > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser:
> > >not set
> > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost:
> > >not set
> > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok
> > >type: 1
> > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100):
> > >newauthtok type: 0
> > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 1
> > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid:
> > >29218
> > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_print_data] (0x0100): logon
> > >name: test
> > >(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_dp_issue_request] (0x0400):
> > >Issuing request for [0x7f4f20215ed0:3:t...@test.example.com]
> > >(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_dp_get_account_msg] (0x0400):
> > >Creating request for [test.example.com][3][1][name=test]
> > >(Mon May 11 14:40:28 2015) [sssd[pam]] [sss_dp_internal_get_send] (0x0400):
> > >Entering request [0x7f4f20215ed0:3:t...@test.example.com]
> > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_check_user_search] (0x0100):
> > >Requesting info for [t...@test.example.com]
> > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_check_user_search] (0x0400):
> > >Returning info for user [t...@test.example.com]
> > >(Mon May 11 14:40:28 2015) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending
> > >reques

Re: [Freeipa-users] How to handle users with multiple homedirs on different machines?

[Sumit Bose]

On Wed, Jun 03, 2015 at 08:29:20AM +0200, Lukas Slebodnik wrote:
> On (02/06/15 17:07), swartz wrote:
> >I have a environment that spans across multiple physical locations where
> >there is a mix of Linux and Solaris workstations/servers. So far we've been
> >managing accounts (/etc/password) via Puppet.
> >
> >Problem: FreeIPA allows to store only one homedir path.
> >Q: Is there a way to store/set a different home path based on the system
> >that the user is logged into?
> >
> sssd configuration is quite flexible in this way.
> You can override homedir with configuration option
> man sssd.conf -> "override_homedir"
> 
> However sssd is available just on linux (or FreeBSD)
> I'm not sure which clients do you use on Solaris or other
> old system, maybe there is a way how to override homedir as well.
> Or you can configure home directory attribute to the non-existing
> attribute in FreeIPA and use some fallback (if possible)
> 
> >As an example, I have user Bob.
> >On a Linux box Bob has homedir at /home/b/bob
>  ^
> Unfortunatelly, there's no way how to say
> sssd to use just first letter from name.
> >On a Solaris this is likely /export/home/bob
> >While on some other odd system it could be /mnt/nas/users/bob
> Different "prefix" for homedir "/export/home", "/home", "/mnt/nas/users"
> could be addresed with the option homedir_substring in sssd conf.
> https://fedorahosted.org/sssd/ticket/1853
> 
> So you could store "%H" in ldap attribute,
> but clients need to understand such value.
> (sssd >= 1.11.6). I'm not sure about other clients.

As an alternative since version 4.1 FreeIPA has a feature called idviews
which can be used to override home-directories for a group of hosts. See
e.g.
http://www.freeipa.org/page/V4/Migrating_existing_environments_to_Trust
or
http://blog.delouw.ch/2015/04/06/migrating-legacy-servers-to-freeipa-authentication-using-id-views/
for details and how to use it.

HTH

bye,
Sumit

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

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

Re: [Freeipa-users] Cannot login with GSSAPI to IPA client

[Sumit Bose]

On Tue, Jun 16, 2015 at 04:32:31PM -0700, nat...@nathanpeters.com wrote:
> I have 2 CentOS 6 clients both running FreeIPA client 3.0.0-42 and sssd
> 1.11.6-30.  The server is CentOS 7 / IPA 4.1.3
> 
> When I try to log in using MIT kerberos and a valid ticket it works on one
> client, and fails on the other.  I have compared the /etc/krb5.conf,
> /etc/sssd/sssd.conf and /etc/openldap/ldap.conf files on both clients and
> they are identical (other than the hostnames).  I can't seem to find any
> other difference between the clients.
> 
> Password authentication works on both machines.
> 
> Here is the dub log of the failed login machine (sshd)
> 
> I think the relevant line is the very last one where it postpones the
> login for some reason
> 
> Postponed gssapi-with-mic for username from 10.5.5.57 port 15076 ssh2

This message is in the other log as well and I think this is ok.

Have you check if the keytab on the host with issue has the latest key
version?

To check the call 'klist -k' as root on the server and then call 'kvno
host/...' with the principal shown in the klist output. Both kvno
numbers should be the same. If they differ call ipa-getkeytab on the
server to get a fresh keytab. Please note that you have to call kdestory
and kinit on the client to remove the old now invalid ticket from the
client's credential cache.

HTH

bye,
Sumit
> ===
> [root@fe1 pam.d]# /usr/sbin/sshd -p 22 -D -ddd -e
> debug2: load_server_config: filename /etc/ssh/sshd_config
> debug2: load_server_config: done config len = 687
> debug2: parse_server_config: config /etc/ssh/sshd_config len 687
> debug3: /etc/ssh/sshd_config:21 setting Protocol 2
> debug3: /etc/ssh/sshd_config:36 setting SyslogFacility AUTHPRIV
> debug3: /etc/ssh/sshd_config:66 setting PasswordAuthentication yes
> debug3: /etc/ssh/sshd_config:70 setting ChallengeResponseAuthentication no
> debug3: /etc/ssh/sshd_config:82 setting GSSAPICleanupCredentials yes
> debug3: /etc/ssh/sshd_config:98 setting AcceptEnv LANG LC_CTYPE LC_NUMERIC
> LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
> debug3: /etc/ssh/sshd_config:99 setting AcceptEnv LC_PAPER LC_NAME
> LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
> debug3: /etc/ssh/sshd_config:100 setting AcceptEnv LC_IDENTIFICATION
> LC_ALL LANGUAGE
> debug3: /etc/ssh/sshd_config:101 setting AcceptEnv XMODIFIERS
> debug3: /etc/ssh/sshd_config:107 setting X11Forwarding yes
> debug3: /etc/ssh/sshd_config:120 setting UseDNS no
> debug3: /etc/ssh/sshd_config:130 setting Subsystem sftp   
> /usr/libexec/openssh/sftp-server
> debug3: /etc/ssh/sshd_config:137 setting KerberosAuthentication no
> debug3: /etc/ssh/sshd_config:138 setting PubkeyAuthentication yes
> debug3: /etc/ssh/sshd_config:139 setting UsePAM yes
> debug3: /etc/ssh/sshd_config:140 setting GSSAPIAuthentication yes
> debug3: /etc/ssh/sshd_config:141 setting AuthorizedKeysCommand
> /usr/bin/sss_ssh_authorizedkeys
> debug1: sshd version OpenSSH_5.3p1
> debug3: Not a RSA1 key file /etc/ssh/ssh_host_rsa_key.
> debug1: read PEM private key done: type RSA
> debug1: private host key: #0 type 1 RSA
> debug3: Not a RSA1 key file /etc/ssh/ssh_host_dsa_key.
> debug1: read PEM private key done: type DSA
> debug1: private host key: #1 type 2 DSA
> debug1: rexec_argv[0]='/usr/sbin/sshd'
> debug1: rexec_argv[1]='-p'
> debug1: rexec_argv[2]='22'
> debug1: rexec_argv[3]='-D'
> debug1: rexec_argv[4]='-ddd'
> debug1: rexec_argv[5]='-e'
> debug3: oom_adjust_setup
> Set /proc/self/oom_score_adj from 0 to -1000
> debug2: fd 3 setting O_NONBLOCK
> debug1: Bind to port 22 on 0.0.0.0.
> Server listening on 0.0.0.0 port 22.
> debug2: fd 4 setting O_NONBLOCK
> debug1: Bind to port 22 on ::.
> Server listening on :: port 22.
> debug3: fd 5 is not O_NONBLOCK
> debug1: Server will not fork when running in debugging mode.
> debug3: send_rexec_state: entering fd = 8 config len 687
> debug3: ssh_msg_send: type 0
> debug3: send_rexec_state: done
> debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
> debug3: recv_rexec_state: entering fd = 5
> debug3: ssh_msg_recv entering
> debug3: recv_rexec_state: done
> debug2: parse_server_config: config rexec len 687
> debug3: rexec:21 setting Protocol 2
> debug3: rexec:36 setting SyslogFacility AUTHPRIV
> debug3: rexec:66 setting PasswordAuthentication yes
> debug3: rexec:70 setting ChallengeResponseAuthentication no
> debug3: rexec:82 setting GSSAPICleanupCredentials yes
> debug3: rexec:98 setting AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME
> LC_COLLATE LC_MONETARY LC_MESSAGES
> debug3: rexec:99 setting AcceptEnv LC_PAPER LC_NAME LC_ADDRESS
> LC_TELEPHONE LC_MEASUREMENT
> debug3: rexec:100 setting AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
> debug3: rexec:101 setting AcceptEnv XMODIFIERS
> debug3: rexec:107 setting X11Forwarding yes
> debug3: rexec:120 setting UseDNS no
> debug3: rexec:130 setting Subsystem sftp/usr/libexec/openssh/sftp-server
> debug3: rexec:137 setting KerberosAuthentication no
> debug3: rexec:138 setting

Re: [Freeipa-users] Question for AD trust and Webservices

[Sumit Bose]

On Wed, Jun 17, 2015 at 08:21:22AM +, Henry Hofmann wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> > It should be possible, yes - if you target web service/Red Mine to the 
> > compat tree, as it was done for example in this integration:
> >
> > http://www.freeipa.org/page/HowTo/vsphere5_integration
> Tanks, your expression is very helpful for nested group memberships.
> 
> But maybe I expressed myself wrong. We need to logon with an user from Active 
> Directory (like henry) over an Trust with the IPA Domain. But in the IPA 
> domain there aren't a user named henry. Only a reference in the group 
> "ipaExternalMember=S-1-5-21-969530201-4059800132-1833743323-1235" to the user.

The user can be looked up in the compat tree, e.g.

ldapsearch -x -b 'cn=compat,dc=ipa,dc=domain' 'uid=henry@ad.domain'

HTH

bye,
Sumit

> 
> >
> > BTW, if Redmine is run by Apache, you can also leverage native 
> > Web<->SSSD<->FreeIPA/AD integration, following
> Our Redmine is running with an ruby webserver based on lock files and in the 
> front we used an nginx webproxy.
> 
> > http://www.freeipa.org/page/Web_App_Authentication
> >
> > Martin
> 
> 
> >> I understand this is for application which is using Kerberos.
> > No, it is not only for that.
> 
> >> I have some web applications like "redmine" and "owncloud" which have a 
> >> own user management. They needs to be configure to LDAP to grant 
> >> authorizations without Kerberos. And not all of them used apache or 
> >> tomcat as application server.
> > For OwnCloud use
> > https://apps.owncloud.com/content/show.php/Unix+user+backend?content=148406
> > and read a backstory in https://github.com/owncloud/core/issues/10130
> >
> > For redmine use http://www.redmine.org/plugins/redmine_pam_auth. You don't 
> > need to include the user which runs redmine into shadow group with FreeIPA 
> > because user accounts are never in > /etc/shadow for FreeIPA so you don't 
> > need that access.
> >
> What you mean with " You don't need to include the user which runs Redmine 
> into shadow group with FreeIPA because user accounts are never in > 
> /etc/shadow for FreeIPA so you don't need that access ".
> Normally we create users and groups in FreeIPA, add the users to the groups. 
> Currently we sync the user and groups to Redmine and grant the permission 
> roles (Developer or Manager) to the groups. In this scenario I can manage 
> remotely the grants for user in every webserver that we used.
> 
> > Both these methods rely on PAM authentication which is powered by SSSD.
> >
> > --
> > / Alexander Bokovoy
> 
> Thanks for your help.
> Henry
> 
> 
> -BEGIN PGP SIGNATURE-
> Version: PGP Universal 3.1.0 (Build 860)
> Charset: us-ascii
> 
> wsBVAwUBVYEuBHEu+nQzo7NUAQhF5ggAhRRwwTW2XkV4wqe3Q4IAbLFvux8KrVpC
> MZ5qovGeyY5N9Fk/MunfC0eg2J2t7KGU9bdJEuWNIZtxH8tLZudRIQL7DMrUs0hF
> yNoCIfa0PgMNhS7OFGMtlpF76YBsA50xP9Qhd8hXOsGMnqaaaZ54psUCO4fOSiLB
> RGFXaFIs6u1odq93DRImVGvy2mBN1MPC+cG1fQHZN089OZ7aFQunNTIWeGptmTX8
> CjspbonsB1HZzN7vRDLs2RKGLm+7f8gv4MZHN1gBFLzTjAAZ1ke2+vOM+e+QmHXL
> GHCx9yPr3C9GvB89cN5tssD/F32Pixa0UzENYAk7CHqQE7cKRpNAOw==
> =jfYn
> -END PGP SIGNATURE-
> 
> -- 
> 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

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

Re: [Freeipa-users] Very Odd Fedora 21 Auth Issue (Server: IPA 4.1.0)

[Sumit Bose]

On Tue, Jun 23, 2015 at 05:24:32PM +1000, craig.red...@shakenautomotive.com.au 
wrote:
> Hi, 
> This is one odd issue?!
> 
> Red Hat Enterprise Linux 7.1
> 
> #Server Side
> Red Hat Enterprise Linux Server release 7.1 (Maipo)
> ipa-server-4.1.0-18.el7_1.3.x86_64
> 
> #Client side
> Fedora release 21 (Twenty One)
> * freeipa-client-4.1.4-1.fc21.x86_64
> * sssd-client-1.12.4-3.fc21.x86_64
> 
> 
> Issue:
> User cannot login to their PC 
> 
> Error: /var/log/secure
> Jun 23 17:08:48 johnpc sshd[3591]: pam_unix(sshd:auth): authentication
> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=localhost  user=john
> Jun 23 17:08:48 johnpc sshd[3591]: pam_sss(sshd:auth): authentication
> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=localhost user=john
> Jun 23 17:08:48 johnpc sshd[3591]: pam_sss(sshd:auth): received for user
> john: 7 (Authentication failure)
> 
> However:
> 1. Kerberous works;
> kinit john 
> john@johnpc /etc/pam.d> klist
> Ticket cache: KEYRING:persistent:365:365
> Default principal: j...@example.exampleaus.com.au
> 
> Valid starting ExpiresService principal
> 23/06/15 16:49:30  24/06/15 16:49:28
> krbtgt/example.exampleaus.com...@example.exampleaus.com.au
> 
> 2. LDAP works;
> john@johnpc ~> getent passwd john
> john:x:365:132::/home/john:/bin/bash
> 
> 3. ssh to IPA server works with a password (so not relying on the kerberous
> ticket);
> john@erio ~> ssh john@sysvm-ipa1
> john@sysvm-ipa1's password: 
> Last login: Tue Jun 23 16:50:02 2015 from johnpc.example.exampleaus.com.au
> 
> 
> Any advice would be greatly appreciated? 

I think we need sssd logs here, please see
https://fedorahosted.org/sssd/wiki/Troubleshooting for details. We need
at least logs for the PAM responder ([pam] section in sssd.conf) and
the backend ([domain/...] section in sssd.conf).

bye,
Sumit

> 
> Regards,
> 
> Craig
> 
> -- 
> 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

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

Re: [Freeipa-users] UPN suffixes in AD trust

[Sumit Bose]

On Wed, Jun 24, 2015 at 05:11:07PM +0200, Giorgio Biacchi wrote:
> Hi everybody,
> I established a bidirectional trust between an IPA server (version 4.1.0 on
> CentOS 7.1), ipa.mydomain.local and an AD (Windows 2012 r2), mydomain.local.
> Everything is working fine, and I'm able to authenticate and logon on a linux
> host joined to IPA server using AD credentials (username@mydomain.local).
> But active directory is configured with two more UPN suffixes (otherdomain.com
> and sub.otherdomain.com), and I cannot logon with credentials using 
> alternative
> UPN (example: john@otherdomain.com).
> 
> How can I make this possible? Another trust (ipa trust-add) with the same AD?
> Manual configuration of krb5 and/or sssd?

Have you tried to login to an IPA client or the server? Please try with
an IPA server first. If this does not work it would be nice if you can
send the SSSD log files from the IPA server which are generated during
the logon attempt. Please call 'sss_cache -E' before to invalidate all
cached entries so that the logs will contain all needed calls to AD.

Using UPN suffixes were added to the AD provider some time ago and the
code is available in the IPA provider as well, but I guess no one has
actually tried this before.

bye,
Sumit

> 
> Thanks in advance
> 
> -- 
> gb
> 
> PGP Key: http://pgp.mit.edu/
> Primary key fingerprint: C510 0765 943E EBED A4F2 69D3 16CC DC90 B9CB 0F34
> 
> -- 
> 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

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

Re: [Freeipa-users] UPN suffixes in AD trust

[Sumit Bose]

On Thu, Jun 25, 2015 at 12:22:16PM +0200, Giorgio Biacchi wrote:
> On 06/24/2015 06:45 PM, Sumit Bose wrote:
> > On Wed, Jun 24, 2015 at 05:11:07PM +0200, Giorgio Biacchi wrote:
> >> Hi everybody,
> >> I established a bidirectional trust between an IPA server (version 4.1.0 on
> >> CentOS 7.1), ipa.mydomain.local and an AD (Windows 2012 r2), 
> >> mydomain.local.
> >> Everything is working fine, and I'm able to authenticate and logon on a 
> >> linux
> >> host joined to IPA server using AD credentials (username@mydomain.local).
> >> But active directory is configured with two more UPN suffixes 
> >> (otherdomain.com
> >> and sub.otherdomain.com), and I cannot logon with credentials using 
> >> alternative
> >> UPN (example: john@otherdomain.com).
> >>
> >> How can I make this possible? Another trust (ipa trust-add) with the same 
> >> AD?
> >> Manual configuration of krb5 and/or sssd?
> > 
> > Have you tried to login to an IPA client or the server? Please try with
> > an IPA server first. If this does not work it would be nice if you can
> > send the SSSD log files from the IPA server which are generated during
> > the logon attempt. Please call 'sss_cache -E' before to invalidate all
> > cached entries so that the logs will contain all needed calls to AD.
> > 
> > Using UPN suffixes were added to the AD provider some time ago and the
> > code is available in the IPA provider as well, but I guess no one has
> > actually tried this before.
> > 
> > bye,
> > Sumit
> 
> First of all let me say that i feel like I'm missing some config somewhere..
> Changes tried in krb5.conf to support UPN suffixes didn't helped.
> I can only access the server vi ssh so I've attached the logs for a successful
> login for account1@mydomain.local and an unsuccessful login for
> accou...@otherdomain.com done via ssh.
> 
> Bye and thanks for your help
> 

It looks like the request is not properly propagated to sub-domains (the
trusted AD domain) but only send to the IPA domain.

Would it be possible for you to run a test build of SSSD which might fix
this? If yes, which version of SSSD are you currently using? Then I can
prepare a test build with the patch on top of this version.

bye,
Sumit

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

Re: [Freeipa-users] UPN suffixes in AD trust

[Sumit Bose]

On Thu, Jun 25, 2015 at 01:06:22PM +0200, Giorgio Biacchi wrote:
> On 06/25/2015 12:56 PM, Sumit Bose wrote:
> > On Thu, Jun 25, 2015 at 12:22:16PM +0200, Giorgio Biacchi wrote:
> >> On 06/24/2015 06:45 PM, Sumit Bose wrote:
> >>> On Wed, Jun 24, 2015 at 05:11:07PM +0200, Giorgio Biacchi wrote:
> >>>> Hi everybody,
> >>>> I established a bidirectional trust between an IPA server (version 4.1.0 
> >>>> on
> >>>> CentOS 7.1), ipa.mydomain.local and an AD (Windows 2012 r2), 
> >>>> mydomain.local.
> >>>> Everything is working fine, and I'm able to authenticate and logon on a 
> >>>> linux
> >>>> host joined to IPA server using AD credentials (username@mydomain.local).
> >>>> But active directory is configured with two more UPN suffixes 
> >>>> (otherdomain.com
> >>>> and sub.otherdomain.com), and I cannot logon with credentials using 
> >>>> alternative
> >>>> UPN (example: john@otherdomain.com).
> >>>>
> >>>> How can I make this possible? Another trust (ipa trust-add) with the 
> >>>> same AD?
> >>>> Manual configuration of krb5 and/or sssd?
> >>>
> >>> Have you tried to login to an IPA client or the server? Please try with
> >>> an IPA server first. If this does not work it would be nice if you can
> >>> send the SSSD log files from the IPA server which are generated during
> >>> the logon attempt. Please call 'sss_cache -E' before to invalidate all
> >>> cached entries so that the logs will contain all needed calls to AD.
> >>>
> >>> Using UPN suffixes were added to the AD provider some time ago and the
> >>> code is available in the IPA provider as well, but I guess no one has
> >>> actually tried this before.
> >>>
> >>> bye,
> >>> Sumit
> >>
> >> First of all let me say that i feel like I'm missing some config 
> >> somewhere..
> >> Changes tried in krb5.conf to support UPN suffixes didn't helped.
> >> I can only access the server vi ssh so I've attached the logs for a 
> >> successful
> >> login for account1@mydomain.local and an unsuccessful login for
> >> accou...@otherdomain.com done via ssh.
> >>
> >> Bye and thanks for your help
> >>
> > 
> > It looks like the request is not properly propagated to sub-domains (the
> > trusted AD domain) but only send to the IPA domain.
> > 
> > Would it be possible for you to run a test build of SSSD which might fix
> > this? If yes, which version of SSSD are you currently using? Then I can
> > prepare a test build with the patch on top of this version.
> > 
> > bye,
> > Sumit
> > 
> 
> Hi,
> I'm using sssd 1.12.2 (sssd --version) on CentOS 7.1.1503 and I'm available 
> for
> any test.
> 
> Here's the packages version for sssd:
> 
> sssd-common-1.12.2-58.el7_1.6.x86_64
> sssd-krb5-1.12.2-58.el7_1.6.x86_64
> python-sssdconfig-1.12.2-58.el7_1.6.noarch
> sssd-krb5-common-1.12.2-58.el7_1.6.x86_64
> sssd-ipa-1.12.2-58.el7_1.6.x86_64
> sssd-1.12.2-58.el7_1.6.x86_64
> sssd-libwbclient-1.12.2-58.el7_1.6.x86_64
> sssd-ad-1.12.2-58.el7_1.6.x86_64
> sssd-ldap-1.12.2-58.el7_1.6.x86_64
> sssd-common-pac-1.12.2-58.el7_1.6.x86_64
> sssd-proxy-1.12.2-58.el7_1.6.x86_64
> sssd-client-1.12.2-58.el7_1.6.x86_64

Please try the packages at
http://koji.fedoraproject.org/koji/taskinfo?taskID=10210844 .

bye,
Sumit

> 
> Thanks again
> -- 
> gb
> 
> PGP Key: http://pgp.mit.edu/
> Primary key fingerprint: C510 0765 943E EBED A4F2 69D3 16CC DC90 B9CB 0F34

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

Re: [Freeipa-users] UPN suffixes in AD trust

[Sumit Bose]

On Thu, Jun 25, 2015 at 04:29:37PM +0200, Giorgio Biacchi wrote:
> On 06/25/2015 02:10 PM, Sumit Bose wrote:
> > On Thu, Jun 25, 2015 at 01:06:22PM +0200, Giorgio Biacchi wrote:
> >> On 06/25/2015 12:56 PM, Sumit Bose wrote:
> >>> On Thu, Jun 25, 2015 at 12:22:16PM +0200, Giorgio Biacchi wrote:
> >>>> On 06/24/2015 06:45 PM, Sumit Bose wrote:
> >>>>> On Wed, Jun 24, 2015 at 05:11:07PM +0200, Giorgio Biacchi wrote:
> >>>>>> Hi everybody,
> >>>>>> I established a bidirectional trust between an IPA server (version 
> >>>>>> 4.1.0 on
> >>>>>> CentOS 7.1), ipa.mydomain.local and an AD (Windows 2012 r2), 
> >>>>>> mydomain.local.
> >>>>>> Everything is working fine, and I'm able to authenticate and logon on 
> >>>>>> a linux
> >>>>>> host joined to IPA server using AD credentials 
> >>>>>> (username@mydomain.local).
> >>>>>> But active directory is configured with two more UPN suffixes 
> >>>>>> (otherdomain.com
> >>>>>> and sub.otherdomain.com), and I cannot logon with credentials using 
> >>>>>> alternative
> >>>>>> UPN (example: john@otherdomain.com).
> >>>>>>
> >>>>>> How can I make this possible? Another trust (ipa trust-add) with the 
> >>>>>> same AD?
> >>>>>> Manual configuration of krb5 and/or sssd?
> >>>>>
> >>>>> Have you tried to login to an IPA client or the server? Please try with
> >>>>> an IPA server first. If this does not work it would be nice if you can
> >>>>> send the SSSD log files from the IPA server which are generated during
> >>>>> the logon attempt. Please call 'sss_cache -E' before to invalidate all
> >>>>> cached entries so that the logs will contain all needed calls to AD.
> >>>>>
> >>>>> Using UPN suffixes were added to the AD provider some time ago and the
> >>>>> code is available in the IPA provider as well, but I guess no one has
> >>>>> actually tried this before.
> >>>>>
> >>>>> bye,
> >>>>> Sumit
> >>>>
> >>>> First of all let me say that i feel like I'm missing some config 
> >>>> somewhere..
> >>>> Changes tried in krb5.conf to support UPN suffixes didn't helped.
> >>>> I can only access the server vi ssh so I've attached the logs for a 
> >>>> successful
> >>>> login for account1@mydomain.local and an unsuccessful login for
> >>>> accou...@otherdomain.com done via ssh.
> >>>>
> >>>> Bye and thanks for your help
> >>>>
> >>>
> >>> It looks like the request is not properly propagated to sub-domains (the
> >>> trusted AD domain) but only send to the IPA domain.
> >>>
> >>> Would it be possible for you to run a test build of SSSD which might fix
> >>> this? If yes, which version of SSSD are you currently using? Then I can
> >>> prepare a test build with the patch on top of this version.
> >>>
> >>> bye,
> >>> Sumit
> >>>
> >>
> >> Hi,
> >> I'm using sssd 1.12.2 (sssd --version) on CentOS 7.1.1503 and I'm 
> >> available for
> >> any test.
> >>
> >> Here's the packages version for sssd:
> >>
> >> sssd-common-1.12.2-58.el7_1.6.x86_64
> >> sssd-krb5-1.12.2-58.el7_1.6.x86_64
> >> python-sssdconfig-1.12.2-58.el7_1.6.noarch
> >> sssd-krb5-common-1.12.2-58.el7_1.6.x86_64
> >> sssd-ipa-1.12.2-58.el7_1.6.x86_64
> >> sssd-1.12.2-58.el7_1.6.x86_64
> >> sssd-libwbclient-1.12.2-58.el7_1.6.x86_64
> >> sssd-ad-1.12.2-58.el7_1.6.x86_64
> >> sssd-ldap-1.12.2-58.el7_1.6.x86_64
> >> sssd-common-pac-1.12.2-58.el7_1.6.x86_64
> >> sssd-proxy-1.12.2-58.el7_1.6.x86_64
> >> sssd-client-1.12.2-58.el7_1.6.x86_64
> > 
> > Please try the packages at
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=10210844 .
> > 
> > bye,
> > Sumit
> 
> Hi,
> I've installed the new RPMs, now if I run on the server:
> 
> id account1@mydomain.local
> id accou...@otherdomain.com
> id accou...@sub.otherdomain.com
> 
> all the users are found but I'm still unable to log in via ssh with the 
> accounts
> @otherdomain.com and @sub.otherdomain.com.
> 
> In attachment the logs for unsuccessful login for user 
> accou...@otherdomain.com.

Bother, I forgot to add the fix to the pam responder as well, please try
new packages from
http://koji.fedoraproject.org/koji/taskinfo?taskID=10212212 .

bye,
Sumit

> 
> Bye
> -- 
> gb
> 
> PGP Key: http://pgp.mit.edu/
> Primary key fingerprint: C510 0765 943E EBED A4F2 69D3 16CC DC90 B9CB 0F34

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

Re: [Freeipa-users] UPN suffixes in AD trust

[Sumit Bose]

On Thu, Jun 25, 2015 at 07:00:34PM +0200, Giorgio Biacchi wrote:
> On 06/25/2015 05:44 PM, Sumit Bose wrote:
> > On Thu, Jun 25, 2015 at 04:29:37PM +0200, Giorgio Biacchi wrote:
> >> On 06/25/2015 02:10 PM, Sumit Bose wrote:
> >>> On Thu, Jun 25, 2015 at 01:06:22PM +0200, Giorgio Biacchi wrote:
> >>>> On 06/25/2015 12:56 PM, Sumit Bose wrote:
> >>>>> On Thu, Jun 25, 2015 at 12:22:16PM +0200, Giorgio Biacchi wrote:
> >>>>>> On 06/24/2015 06:45 PM, Sumit Bose wrote:
> >>>>>>> On Wed, Jun 24, 2015 at 05:11:07PM +0200, Giorgio Biacchi wrote:
> >>>>>>>> Hi everybody,
> >>>>>>>> I established a bidirectional trust between an IPA server (version 
> >>>>>>>> 4.1.0 on
> >>>>>>>> CentOS 7.1), ipa.mydomain.local and an AD (Windows 2012 r2), 
> >>>>>>>> mydomain.local.
> >>>>>>>> Everything is working fine, and I'm able to authenticate and logon 
> >>>>>>>> on a linux
> >>>>>>>> host joined to IPA server using AD credentials 
> >>>>>>>> (username@mydomain.local).
> >>>>>>>> But active directory is configured with two more UPN suffixes 
> >>>>>>>> (otherdomain.com
> >>>>>>>> and sub.otherdomain.com), and I cannot logon with credentials using 
> >>>>>>>> alternative
> >>>>>>>> UPN (example: john@otherdomain.com).
> >>>>>>>>
> >>>>>>>> How can I make this possible? Another trust (ipa trust-add) with the 
> >>>>>>>> same AD?
> >>>>>>>> Manual configuration of krb5 and/or sssd?
> >>>>>>>
> >>>>>>> Have you tried to login to an IPA client or the server? Please try 
> >>>>>>> with
> >>>>>>> an IPA server first. If this does not work it would be nice if you can
> >>>>>>> send the SSSD log files from the IPA server which are generated during
> >>>>>>> the logon attempt. Please call 'sss_cache -E' before to invalidate all
> >>>>>>> cached entries so that the logs will contain all needed calls to AD.
> >>>>>>>
> >>>>>>> Using UPN suffixes were added to the AD provider some time ago and the
> >>>>>>> code is available in the IPA provider as well, but I guess no one has
> >>>>>>> actually tried this before.
> >>>>>>>
> >>>>>>> bye,
> >>>>>>> Sumit
> >>>>>>
> >>>>>> First of all let me say that i feel like I'm missing some config 
> >>>>>> somewhere..
> >>>>>> Changes tried in krb5.conf to support UPN suffixes didn't helped.
> >>>>>> I can only access the server vi ssh so I've attached the logs for a 
> >>>>>> successful
> >>>>>> login for account1@mydomain.local and an unsuccessful login for
> >>>>>> accou...@otherdomain.com done via ssh.
> >>>>>>
> >>>>>> Bye and thanks for your help
> >>>>>>
> >>>>>
> >>>>> It looks like the request is not properly propagated to sub-domains (the
> >>>>> trusted AD domain) but only send to the IPA domain.
> >>>>>
> >>>>> Would it be possible for you to run a test build of SSSD which might fix
> >>>>> this? If yes, which version of SSSD are you currently using? Then I can
> >>>>> prepare a test build with the patch on top of this version.
> >>>>>
> >>>>> bye,
> >>>>> Sumit
> >>>>>
> >>>>
> >>>> Hi,
> >>>> I'm using sssd 1.12.2 (sssd --version) on CentOS 7.1.1503 and I'm 
> >>>> available for
> >>>> any test.
> >>>>
> >>>> Here's the packages version for sssd:
> >>>>
> >>>> sssd-common-1.12.2-58.el7_1.6.x86_64
> >>>> sssd-krb5-1.12.2-58.el7_1.6.x86_64
> >>>> python-sssdconfig-1.12.2-58.el7_1.6.noarch
> >>>> sssd-krb5-common-1.12.2-58.el7_1.6.x86_64
> >>>> sssd-ipa-1.12.2-58.el7_1.6.x86_64
> >>>> s

Re: [Freeipa-users] UPN suffixes in AD trust

[Sumit Bose]

On Fri, Jun 26, 2015 at 04:34:05PM +0200, Giorgio Biacchi wrote:
> 
> 
> On 06/26/2015 02:38 PM, Sumit Bose wrote:
> > On Thu, Jun 25, 2015 at 07:00:34PM +0200, Giorgio Biacchi wrote:
> >> On 06/25/2015 05:44 PM, Sumit Bose wrote:
> >>> On Thu, Jun 25, 2015 at 04:29:37PM +0200, Giorgio Biacchi wrote:
> >>>> On 06/25/2015 02:10 PM, Sumit Bose wrote:
> >>>>> On Thu, Jun 25, 2015 at 01:06:22PM +0200, Giorgio Biacchi wrote:
> >>>>>> On 06/25/2015 12:56 PM, Sumit Bose wrote:
> >>>>>>> On Thu, Jun 25, 2015 at 12:22:16PM +0200, Giorgio Biacchi wrote:
> >>>>>>>> On 06/24/2015 06:45 PM, Sumit Bose wrote:
> >>>>>>>>> On Wed, Jun 24, 2015 at 05:11:07PM +0200, Giorgio Biacchi wrote:
> >>>>>>>>>> Hi everybody,
> >>>>>>>>>> I established a bidirectional trust between an IPA server (version 
> >>>>>>>>>> 4.1.0 on
> >>>>>>>>>> CentOS 7.1), ipa.mydomain.local and an AD (Windows 2012 r2), 
> >>>>>>>>>> mydomain.local.
> >>>>>>>>>> Everything is working fine, and I'm able to authenticate and logon 
> >>>>>>>>>> on a linux
> >>>>>>>>>> host joined to IPA server using AD credentials 
> >>>>>>>>>> (username@mydomain.local).
> >>>>>>>>>> But active directory is configured with two more UPN suffixes 
> >>>>>>>>>> (otherdomain.com
> >>>>>>>>>> and sub.otherdomain.com), and I cannot logon with credentials 
> >>>>>>>>>> using alternative
> >>>>>>>>>> UPN (example: john@otherdomain.com).
> >>>>>>>>>>
> >>>>>>>>>> How can I make this possible? Another trust (ipa trust-add) with 
> >>>>>>>>>> the same AD?
> >>>>>>>>>> Manual configuration of krb5 and/or sssd?
> >>>>>>>>>
> >>>>>>>>> Have you tried to login to an IPA client or the server? Please try 
> >>>>>>>>> with
> >>>>>>>>> an IPA server first. If this does not work it would be nice if you 
> >>>>>>>>> can
> >>>>>>>>> send the SSSD log files from the IPA server which are generated 
> >>>>>>>>> during
> >>>>>>>>> the logon attempt. Please call 'sss_cache -E' before to invalidate 
> >>>>>>>>> all
> >>>>>>>>> cached entries so that the logs will contain all needed calls to AD.
> >>>>>>>>>
> >>>>>>>>> Using UPN suffixes were added to the AD provider some time ago and 
> >>>>>>>>> the
> >>>>>>>>> code is available in the IPA provider as well, but I guess no one 
> >>>>>>>>> has
> >>>>>>>>> actually tried this before.
> >>>>>>>>>
> >>>>>>>>> bye,
> >>>>>>>>> Sumit
> >>>>>>>>
> >>>>>>>> First of all let me say that i feel like I'm missing some config 
> >>>>>>>> somewhere..
> >>>>>>>> Changes tried in krb5.conf to support UPN suffixes didn't helped.
> >>>>>>>> I can only access the server vi ssh so I've attached the logs for a 
> >>>>>>>> successful
> >>>>>>>> login for account1@mydomain.local and an unsuccessful login for
> >>>>>>>> accou...@otherdomain.com done via ssh.
> >>>>>>>>
> >>>>>>>> Bye and thanks for your help
> >>>>>>>>
> >>>>>>>
> >>>>>>> It looks like the request is not properly propagated to sub-domains 
> >>>>>>> (the
> >>>>>>> trusted AD domain) but only send to the IPA domain.
> >>>>>>>
> >>>>>>> Would it be possible for you to run a test build of SSSD which might 
> >>>>>>> fix
> >>>>>>> this? If yes, which version of SSSD are you currently us

Re: [Freeipa-users] UPN suffixes in AD trust

[Sumit Bose]

On Mon, Jun 29, 2015 at 11:24:00AM +0200, Giorgio Biacchi wrote:
> On 06/29/2015 10:30 AM, Sumit Bose wrote:
> > On Mon, Jun 29, 2015 at 10:04:04AM +0200, Giorgio Biacchi wrote:
> >> On 06/26/2015 08:06 PM, Sumit Bose wrote:
> >>> On Fri, Jun 26, 2015 at 04:34:05PM +0200, Giorgio Biacchi wrote:
> >>>>
> >>>>
> >>>> On 06/26/2015 02:38 PM, Sumit Bose wrote:
> >>>>> On Thu, Jun 25, 2015 at 07:00:34PM +0200, Giorgio Biacchi wrote:
> >>>>>> On 06/25/2015 05:44 PM, Sumit Bose wrote:
> >>>>>>> On Thu, Jun 25, 2015 at 04:29:37PM +0200, Giorgio Biacchi wrote:
> >>>>>>>> On 06/25/2015 02:10 PM, Sumit Bose wrote:
> >>>>>>>>> On Thu, Jun 25, 2015 at 01:06:22PM +0200, Giorgio Biacchi wrote:
> >>>>>>>>>> On 06/25/2015 12:56 PM, Sumit Bose wrote:
> >>>>>>>>>>> On Thu, Jun 25, 2015 at 12:22:16PM +0200, Giorgio Biacchi wrote:
> >>>>>>>>>>>> On 06/24/2015 06:45 PM, Sumit Bose wrote:
> >>>>>>>>>>>>> On Wed, Jun 24, 2015 at 05:11:07PM +0200, Giorgio Biacchi wrote:
> >>>>>>>>>>>>>> Hi everybody,
> >>>>>>>>>>>>>> I established a bidirectional trust between an IPA server 
> >>>>>>>>>>>>>> (version 4.1.0 on
> >>>>>>>>>>>>>> CentOS 7.1), ipa.mydomain.local and an AD (Windows 2012 r2), 
> >>>>>>>>>>>>>> mydomain.local.
> >>>>>>>>>>>>>> Everything is working fine, and I'm able to authenticate and 
> >>>>>>>>>>>>>> logon on a linux
> >>>>>>>>>>>>>> host joined to IPA server using AD credentials 
> >>>>>>>>>>>>>> (username@mydomain.local).
> >>>>>>>>>>>>>> But active directory is configured with two more UPN suffixes 
> >>>>>>>>>>>>>> (otherdomain.com
> >>>>>>>>>>>>>> and sub.otherdomain.com), and I cannot logon with credentials 
> >>>>>>>>>>>>>> using alternative
> >>>>>>>>>>>>>> UPN (example: john@otherdomain.com).
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> How can I make this possible? Another trust (ipa trust-add) 
> >>>>>>>>>>>>>> with the same AD?
> >>>>>>>>>>>>>> Manual configuration of krb5 and/or sssd?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Have you tried to login to an IPA client or the server? Please 
> >>>>>>>>>>>>> try with
> >>>>>>>>>>>>> an IPA server first. If this does not work it would be nice if 
> >>>>>>>>>>>>> you can
> >>>>>>>>>>>>> send the SSSD log files from the IPA server which are generated 
> >>>>>>>>>>>>> during
> >>>>>>>>>>>>> the logon attempt. Please call 'sss_cache -E' before to 
> >>>>>>>>>>>>> invalidate all
> >>>>>>>>>>>>> cached entries so that the logs will contain all needed calls 
> >>>>>>>>>>>>> to AD.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Using UPN suffixes were added to the AD provider some time ago 
> >>>>>>>>>>>>> and the
> >>>>>>>>>>>>> code is available in the IPA provider as well, but I guess no 
> >>>>>>>>>>>>> one has
> >>>>>>>>>>>>> actually tried this before.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> bye,
> >>>>>>>>>>>>> Sumit
> >>>>>>>>>>>>
> >>>>>>>>>>>> First of all let me say that i feel like I'm missing some config 
> >>>>>

Re: [Freeipa-users] UPN suffixes in AD trust

[Sumit Bose]

On Mon, Jun 29, 2015 at 03:49:37PM +0200, Jakub Hrozek wrote:
> On Mon, Jun 29, 2015 at 03:11:57PM +0200, Sumit Bose wrote:
> > On Mon, Jun 29, 2015 at 11:24:00AM +0200, Giorgio Biacchi wrote:
> > > On 06/29/2015 10:30 AM, Sumit Bose wrote:
> > > > On Mon, Jun 29, 2015 at 10:04:04AM +0200, Giorgio Biacchi wrote:
> > > >> On 06/26/2015 08:06 PM, Sumit Bose wrote:
> > > >>> On Fri, Jun 26, 2015 at 04:34:05PM +0200, Giorgio Biacchi wrote:
> > > >>>>
> > > >>>>
> > > >>>> On 06/26/2015 02:38 PM, Sumit Bose wrote:
> > > >>>>> On Thu, Jun 25, 2015 at 07:00:34PM +0200, Giorgio Biacchi wrote:
> > > >>>>>> On 06/25/2015 05:44 PM, Sumit Bose wrote:
> > > >>>>>>> On Thu, Jun 25, 2015 at 04:29:37PM +0200, Giorgio Biacchi wrote:
> > > >>>>>>>> On 06/25/2015 02:10 PM, Sumit Bose wrote:
> > > >>>>>>>>> On Thu, Jun 25, 2015 at 01:06:22PM +0200, Giorgio Biacchi wrote:
> > > >>>>>>>>>> On 06/25/2015 12:56 PM, Sumit Bose wrote:
> > > >>>>>>>>>>> On Thu, Jun 25, 2015 at 12:22:16PM +0200, Giorgio Biacchi 
> > > >>>>>>>>>>> wrote:
> > > >>>>>>>>>>>> On 06/24/2015 06:45 PM, Sumit Bose wrote:
> > > >>>>>>>>>>>>> On Wed, Jun 24, 2015 at 05:11:07PM +0200, Giorgio Biacchi 
> > > >>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>> Hi everybody,
> > > >>>>>>>>>>>>>> I established a bidirectional trust between an IPA server 
> > > >>>>>>>>>>>>>> (version 4.1.0 on
> > > >>>>>>>>>>>>>> CentOS 7.1), ipa.mydomain.local and an AD (Windows 2012 
> > > >>>>>>>>>>>>>> r2), mydomain.local.
> > > >>>>>>>>>>>>>> Everything is working fine, and I'm able to authenticate 
> > > >>>>>>>>>>>>>> and logon on a linux
> > > >>>>>>>>>>>>>> host joined to IPA server using AD credentials 
> > > >>>>>>>>>>>>>> (username@mydomain.local).
> > > >>>>>>>>>>>>>> But active directory is configured with two more UPN 
> > > >>>>>>>>>>>>>> suffixes (otherdomain.com
> > > >>>>>>>>>>>>>> and sub.otherdomain.com), and I cannot logon with 
> > > >>>>>>>>>>>>>> credentials using alternative
> > > >>>>>>>>>>>>>> UPN (example: john@otherdomain.com).
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> How can I make this possible? Another trust (ipa 
> > > >>>>>>>>>>>>>> trust-add) with the same AD?
> > > >>>>>>>>>>>>>> Manual configuration of krb5 and/or sssd?
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Have you tried to login to an IPA client or the server? 
> > > >>>>>>>>>>>>> Please try with
> > > >>>>>>>>>>>>> an IPA server first. If this does not work it would be nice 
> > > >>>>>>>>>>>>> if you can
> > > >>>>>>>>>>>>> send the SSSD log files from the IPA server which are 
> > > >>>>>>>>>>>>> generated during
> > > >>>>>>>>>>>>> the logon attempt. Please call 'sss_cache -E' before to 
> > > >>>>>>>>>>>>> invalidate all
> > > >>>>>>>>>>>>> cached entries so that the logs will contain all needed 
> > > >>>>>>>>>>>>> calls to AD.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Using UPN suffixes were added to the AD provider some time 
&

Re: [Freeipa-users] Using FreeIPA OTP in a PAM module

[Sumit Bose]

On Tue, Jun 30, 2015 at 09:09:19AM +0200, Jakub Hrozek wrote:
> On Tue, Jun 30, 2015 at 11:34:55AM +0530, Prashant Bapat wrote:
> > Hi,
> > 
> > I was able to set this up in a Fedora instance with SSSD and it works as
> > expected. SSHD first uses the public key and then prompts for password
> > which is ofcourse password+OTP.
> > 
> > However, having a user enter the password+OTP every time he logs in during
> > the day is kind of inconvenient. Is it possible to make sure the user has
> > to login once and the credentials are cached for say 12/24 hours. I know
> > this is possible just using the password. Question is, is this possible
> > using password+OTP?
> 
> We have an SSSD feature under review now that would help you:
> https://fedorahosted.org/sssd/ticket/1807
> 
> But to be honest, I'm not sure if we tested the patches with 2FA yet. We
> should!

hm, I agree we should, but I guess we should test that cached
authentication does _not_ work with 2FA/OTP. Because it is expected that
the OTP token only works once, so that e.g. it can be used in an
insecure environment to set up a secure tunnel.

Maybe it would make sense to add a paragraph to
https://fedorahosted.org/sssd/wiki/DesignDocs/CachedAuthentication and
discuss OTP/2FA usage here or on sssd-devel.

bye,
Sumit

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

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

Re: [Freeipa-users] Using FreeIPA OTP in a PAM module

[Sumit Bose]

On Tue, Jun 30, 2015 at 09:31:55AM +0200, Jakub Hrozek wrote:
> On Tue, Jun 30, 2015 at 09:22:13AM +0200, Sumit Bose wrote:
> > On Tue, Jun 30, 2015 at 09:09:19AM +0200, Jakub Hrozek wrote:
> > > On Tue, Jun 30, 2015 at 11:34:55AM +0530, Prashant Bapat wrote:
> > > > Hi,
> > > > 
> > > > I was able to set this up in a Fedora instance with SSSD and it works as
> > > > expected. SSHD first uses the public key and then prompts for password
> > > > which is ofcourse password+OTP.
> > > > 
> > > > However, having a user enter the password+OTP every time he logs in 
> > > > during
> > > > the day is kind of inconvenient. Is it possible to make sure the user 
> > > > has
> > > > to login once and the credentials are cached for say 12/24 hours. I know
> > > > this is possible just using the password. Question is, is this possible
> > > > using password+OTP?
> > > 
> > > We have an SSSD feature under review now that would help you:
> > > https://fedorahosted.org/sssd/ticket/1807
> > > 
> > > But to be honest, I'm not sure if we tested the patches with 2FA yet. We
> > > should!
> > 
> > hm, I agree we should, but I guess we should test that cached
> > authentication does _not_ work with 2FA/OTP. Because it is expected that
> > the OTP token only works once, so that e.g. it can be used in an
> > insecure environment to set up a secure tunnel.
> 
> Sure, the second factor must not be reused :-) but couldn't we use the
> cached auth to support cases like this where the second factor is to be
> used only once per some time and use only the first factor in the
> meantime?

I'm a bit reluctant here. If the two factors are intercepted in an
insecure environment the attacker will still have a valid password which
can be used for some time. Additionally, iirc cached authentication is
not aware of the service used. If e.g. OTP was used to just get a
response from some unprotected and unprivileged service the intercepted
password can be used to log in with ssh as well. So I guess we need a
careful discussion here.

bye,
Sumit

> 
> > 
> > Maybe it would make sense to add a paragraph to
> > https://fedorahosted.org/sssd/wiki/DesignDocs/CachedAuthentication and
> > discuss OTP/2FA usage here or on sssd-devel.
> 
> Yes, whatever the result it, it should be documented, also in the man
> pages, because currently it's not clear what happens.

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

Re: [Freeipa-users] username case sensitivity

[Sumit Bose]

On Wed, Jul 01, 2015 at 10:12:54AM +0200, Jakub Hrozek wrote:
> On Tue, Jun 30, 2015 at 08:16:05PM +, Andy Thompson wrote:
> > > > 
> > > > On Fri, May 15, 2015 at 09:44:31PM +0200, Lukas Slebodnik wrote:
> > > > >On (15/05/15 17:27), Andy Thompson wrote:
> > > > >>Is there a way to enforce case sensitivity for trusted AD users?
> > > > >>I am
> > > > >trying to use username for ssh chroots and I can authenticated
> > > > >with any case combination of  but if ssh is set to
> > > > >match on  then the chroot is not enforced and the user
> > > > >is dropped to their usual home directory.  I found a
> > > > >case_sensitive option for sssd but it
> > > > does not
> > > > >seem to have any affect.   Running RHEL6.6 clients.
> > > > >IPA domain is by default case sensitive.
> > > > >So You will not change anything if you put "case_sensitive = true"
> > > > >into domain section of sssd.conf.
> > > > >
> > > > >But SSSD will create subdomains for each AD domain. It is
> > > > >different id_provider therefore different default values are used
> > > > >for subdomains and for AD provider it is case *insensitive* by
> > > default.
> > > > >
> > > > >Currently there's no way how to change it for subdomains (AD
> > > > >trusted
> > > > >domains)
> > > > >
> > > > What are you using for the SSH matching? The way the case
> > > > insensitiveness is implemented in SSSD is that all usernames are
> > > > forcibly lowercased on output, so as long as SSH uses the standard
> > > > NSS calls, you should be good with using the lowecase usernames..
> > > > 
> > > > >>>They were initially all in lower case and working  when I tested
> > > > >>>and finalized
> > > > >>the setup.  I passed the credentials off and they used mixed case
> > > > >>and the match stopped working.
> > > > >>
> > > > >>What is "they" ? I guess not SSSD but grabbing the data directly from
> > > LDAP?
> > > > >The match clauses in the sshd config were set to use lower case names. 
> > > > > It
> > > is using sssd, just a regular ipa client installation.  If I logged in 
> > > using
> > > USERName insetad of username, the match clause did not work.
> > > > >
> > > > >-andy
> > > > >
> > > > Do we have any follow up on this thread? Have we closed the loop and
> > > > filed a ticket.
> > > > I had couple complains of the similar matter during Red Hat Summit.
> > > > I seems that this is one of the emerging issues for the trust 
> > > > environments.
> > > 
> > > I wonder if it's still an issue with 1.12.x and the Kerberos plugin Sumit 
> > > wrote.
> > > Do we have a way to track these requests?
> > > 
> > > Andy, if you have some test machines, could you give 6.7 a try?
> > > 
> > 
> > The usernames from AD are still not case sensitive on 6.7 so a
> > 
> > Match User Testuser
> > 
> > Stanza in the ssh config is not matched if they login as
> > 
> > testuser
> > 
> > but does match if they login with 
> > 
> > Testuser
> 
> Thanks for the reply. Then I guess sshd doesn't canonicalize the
> username with getpwnam(). But I admit I don't know exactly what sshd
> does, so I hope other developers would chime in here..

iirc sshd does call getpwnam() with the name given at the login prompt
to determine if the user exists at all and its home-directory, shell,
UID and GID which is needed later on. But it does not expect that the
name gets canonicalized and continues to use the name given at the login
prompt.

I wonder if it would be possible to use group names in the Match clause
in your setup? Since sshd must call getgroups() and getgrgid() to get
this information here the lower-case group name returned by SSSD should
work.

bye,
Sumit
> 
> -- 
> 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

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

Re: [Freeipa-users] IPA ERROR: non-public: TypeError -- ipa trust-add internal server error

[Sumit Bose]

On Wed, Jul 01, 2015 at 02:37:44PM +0100, David Fox wrote:
> I am encountering issues trying to integrate FreeIPA with AD, on *nix promp
> I get "internal server rror" and within I receive the following message in
> httpd_errorlog.
> 

It looks like we as AD if it already has a trust to a domain called
'ipa.*redacted*' and 

> rpc reply data:
> [] 00 00 02 00 06 00 00 00   03 00 00 00 00 00 00 00    
>  lsa_QueryTrustedDomainInfoByName: struct
> lsa_QueryTrustedDomainInfoByName
> in: struct lsa_QueryTrustedDomainInfoByName
> handle   : *
> handle: struct policy_handle
> handle_type  : 0x (0)
> uuid :
> 0593f50d-b3c4-4b0a-b3d7-f502da1ea0e6
> trusted_domain   : *
> trusted_domain: struct lsa_String
> length   : 0x001a (26)
> size : 0x001a (26)
> string   : *
> string   : 'ipa.*redacted*'
> level: LSA_TRUSTED_DOMAIN_INFO_FULL_INFO (8)
> rpc request data:
> [] 00 00 00 00 0D F5 93 05   C4 B3 0A 4B B3 D7 F5 02    ...K
> [0010] DA 1E A0 E6 1A 00 1A 00   00 00 02 00 0D 00 00 00    
> [0020] 00 00 00 00 0D 00 00 00   69 00 70 00 61 00 2E 00    i.p.a...
> [0030] 68 00 73 00 61 00 2E 00   63 00 6F 00 2E 00 75 00   a... c.o...u.
> [0040] 6B 00 08 00   k...
> s4_tevent: Schedule immediate event "dcerpc_io_trigger": 0x7fdde0230710
> s4_tevent: Added timed event "dcerpc_timeout_handler": 0x7fdde00ef550
> s4_tevent: Run immediate event "dcerpc_io_trigger": 0x7fdde0230710
> s4_tevent: Schedule immediate event "dcerpc_io_trigger": 0x7fdde0230710
> num_setup=2, max_setup=0, param_total=0, this_param=0, max_param=0,
> data_total=92, this_data=92, max_data=4280, param_offset=84, param_pad=2,
> param_disp=0, data_offset=84, data_pad=0, data_disp=0
> s4_tevent: Added timed event "tevent_req_timedout": 0x7fdde00ee2f0
> smb_signing_md5: sequence number 14
> smb_signing_sign_pdu: sent SMB signature of
> [] B0 93 27 43 EE 4A 37 94..'C.J7.
> s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger":
> 0x7fdde00f5a60
> s4_tevent: Run immediate event "dcerpc_io_trigger": 0x7fdde0230710
> s4_tevent: Run immediate event "tevent_queue_immediate_trigger":
> 0x7fdde00f5a60
> smb_signing_md5: sequence number 15
> smb_signing_check_pdu: seq 15: got good SMB signature of
> [] 8F F4 5B 5F 27 39 4C 42..[_'9LB
> s4_tevent: Destroying timer event 0x7fdde00ee2f0 "tevent_req_timedout"
> s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fdde050c440
> s4_tevent: Run immediate event "tevent_req_trigger": 0x7fdde050c440
> s4_tevent: Destroying timer event 0x7fdde00ef550 "dcerpc_timeout_handler"
> s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fdde05110e0
> s4_tevent: Run immediate event "tevent_req_trigger": 0x7fdde05110e0
>  lsa_QueryTrustedDomainInfoByName: struct
> lsa_QueryTrustedDomainInfoByName
> out: struct lsa_QueryTrustedDomainInfoByName
> info : *
> info : *
> info : union
> lsa_TrustedDomainInfo(case 8)
> full_info: struct lsa_TrustDomainInfoFullInfo
> info_ex: struct lsa_TrustDomainInfoInfoEx
> domain_name: struct lsa_StringLarge
> length   : 0x001a (26)
> size : 0x001c (28)
> string   : *
> string   :
> 'ipa.*redacted*'
> netbios_name: struct lsa_StringLarge
> length   : 0x001a (26)
> size : 0x001c (28)
> string   : *
> string   :
> 'ipa.*redacted*'
> sid  : NULL
> trust_direction  : 0x0003 (3)
>1: LSA_TRUST_DIRECTION_INBOUND
>1: LSA_TRUST_DIRECTION_OUTBOUND
> trust_type   : LSA_TRUST_TYPE_MIT


and knows this domain already because a trust to the Kerberos realm was
already created.

If possible please remove the Kerberos trust from the AD side and try
again.

Please note that you cannot have trust to two realms which share the
same realm name.

HTH

bye,
Sumit

> (3)
> 

Re: [Freeipa-users] IPA ERROR: non-public: TypeError -- ipa trust-add internal server error

[Sumit Bose]

On Fri, Jul 03, 2015 at 03:30:38PM +0100, David Fox wrote:
> On 2015-07-02 12:47, Sumit Bose wrote:
> >On Wed, Jul 01, 2015 at 02:37:44PM +0100, David Fox wrote:
> >>I am encountering issues trying to integrate FreeIPA with AD, on *nix
> >>promp
> >>I get "internal server rror" and within I receive the following message
> >>in
> >>httpd_errorlog.
> >>
> >
> >It looks like we as AD if it already has a trust to a domain called
> >'ipa.*redacted*' and 
> >
> >>rpc reply data:
> >>[] 00 00 02 00 06 00 00 00   03 00 00 00 00 00 00 00   
> >>
> >> lsa_QueryTrustedDomainInfoByName: struct
> >>lsa_QueryTrustedDomainInfoByName
> >>in: struct lsa_QueryTrustedDomainInfoByName
> >>handle   : *
> >>handle: struct policy_handle
> >>handle_type  : 0x (0)
> >>uuid :
> >>0593f50d-b3c4-4b0a-b3d7-f502da1ea0e6
> >>trusted_domain   : *
> >>trusted_domain: struct lsa_String
> >>length   : 0x001a (26)
> >>size : 0x001a (26)
> >>string   : *
> >>string   : 'ipa.*redacted*'
> >>level: LSA_TRUSTED_DOMAIN_INFO_FULL_INFO
> >>(8)
> >>rpc request data:
> >>[] 00 00 00 00 0D F5 93 05   C4 B3 0A 4B B3 D7 F5 02   
> >>...K
> >>[0010] DA 1E A0 E6 1A 00 1A 00   00 00 02 00 0D 00 00 00   
> >>
> >>[0020] 00 00 00 00 0D 00 00 00   69 00 70 00 61 00 2E 00   
> >>i.p.a...
> >>[0030] 68 00 73 00 61 00 2E 00   63 00 6F 00 2E 00 75 00   a... c.o...u.
> >>[0040] 6B 00 08 00   k...
> >>s4_tevent: Schedule immediate event "dcerpc_io_trigger": 0x7fdde0230710
> >>s4_tevent: Added timed event "dcerpc_timeout_handler": 0x7fdde00ef550
> >>s4_tevent: Run immediate event "dcerpc_io_trigger": 0x7fdde0230710
> >>s4_tevent: Schedule immediate event "dcerpc_io_trigger": 0x7fdde0230710
> >>num_setup=2, max_setup=0, param_total=0, this_param=0, max_param=0,
> >>data_total=92, this_data=92, max_data=4280, param_offset=84,
> >>param_pad=2,
> >>param_disp=0, data_offset=84, data_pad=0, data_disp=0
> >>s4_tevent: Added timed event "tevent_req_timedout": 0x7fdde00ee2f0
> >>smb_signing_md5: sequence number 14
> >>smb_signing_sign_pdu: sent SMB signature of
> >>[] B0 93 27 43 EE 4A 37 94..'C.J7.
> >>s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger":
> >>0x7fdde00f5a60
> >>s4_tevent: Run immediate event "dcerpc_io_trigger": 0x7fdde0230710
> >>s4_tevent: Run immediate event "tevent_queue_immediate_trigger":
> >>0x7fdde00f5a60
> >>smb_signing_md5: sequence number 15
> >>smb_signing_check_pdu: seq 15: got good SMB signature of
> >>[] 8F F4 5B 5F 27 39 4C 42..[_'9LB
> >>s4_tevent: Destroying timer event 0x7fdde00ee2f0 "tevent_req_timedout"
> >>s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fdde050c440
> >>s4_tevent: Run immediate event "tevent_req_trigger": 0x7fdde050c440
> >>s4_tevent: Destroying timer event 0x7fdde00ef550
> >>"dcerpc_timeout_handler"
> >>s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fdde05110e0
> >>s4_tevent: Run immediate event "tevent_req_trigger": 0x7fdde05110e0
> >> lsa_QueryTrustedDomainInfoByName: struct
> >>lsa_QueryTrustedDomainInfoByName
> >>out: struct lsa_QueryTrustedDomainInfoByName
> >>info : *
> >>info : *
> >>info : union
> >>lsa_TrustedDomainInfo(case 8)
> >>full_info: struct lsa_TrustDomainInfoFullInfo
> >>info_ex: struct lsa_TrustDomainInfoInfoEx
> >>domain_name: struct lsa_StringLarge
> >>length   : 0x001a (26)
> >>size   

Re: [Freeipa-users] sssd and ipa+ad trust, ssh login errors

[Sumit Bose]

On Fri, Jul 03, 2015 at 07:52:12PM +0300, l...@avc.su wrote:
> OK, seems like I've found the cause.
> 
> /etc/sssd/sssd.conf
> default_domain_suffix = zone.local
> 
> If I comment this out, I can login using password or publickey with ipa user
> and using password with AD user, but I need to specify the domain component.
> Found this thread:
> https://www.redhat.com/archives/freeipa-users/2015-February/msg00371.html
> And this bug: https://fedorahosted.org/sssd/ticket/2569
> 
> Since it's fixed, it should appear in sssd 1.13 release?

yes, it is already in the alpha
https://fedorahosted.org/released/sssd/sssd-1.13.0alpha.tar.gz .

bye,
Sumit

> 
> l...@avc.su писал 2015-07-03 18:29:
> >Hello.
> >I've encountered an issue with ssh login to freeipa clients in trusted
> >environment.
> >getent/id commands working as expected, but password/publickey auth
> >for user from ipa or AD domain does not work (gssapi works, by the
> >way)
> >Seems like sss_ssh_authorizedkeys not working properly in this case.
> 
> -- 
> 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

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

Re: [Freeipa-users] strange password error..

[Sumit Bose]

On Mon, Jul 06, 2015 at 02:25:56PM -0700, Janelle wrote:
> On 7/6/15 10:44 AM, Simo Sorce wrote:
> >On Mon, 2015-07-06 at 10:11 -0700, Janelle wrote:
> >>Hello all,
> >>
> >>Is there any known bug that would cause:
> >>
> >>Password change failed. Server message: Current password's minimum life
> >>has not expired
> >>
> >>Here is the environment/process (7.1 with IPA 4.1.4) --
> >>1. reset a user's PW so they are forced to change it.
> >>2. they login and get the "Your password has expired..." message
> >>3. They are then asked to change it and enter a new PW (twice)
> >>4. This error message pops up, BUT -- the password is still changed.
> >If they get this using kpasswd it may happen if a re-transmission
> >occurs, as kpasswd uses UDP, so the second request ends up with that
> >error, I think, not 100% sure.
> >
> >Simo.
> >
> This is very consistent - happening to all my users, and yet the IPA server
> load is nothing. And since it does reset the PW successfully, why would it
> still send this message?

Can you provide the SSSD domain and pam responder log files? If you
prefer feel free to send them to me by pm.

Besides updating the password on the server side SSSD does other things
like e.g. updating the cached password hash. Maybe the server side
update works as expected but some other operation fail causing this
error message.

bye,
Sumit

> 
> Still confused,
> ~Janelle
> 
> -- 
> 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

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

Re: [Freeipa-users] UPN suffixes in AD trust

[Sumit Bose]

On Thu, Jul 09, 2015 at 12:36:53PM +0200, Giorgio Biacchi wrote:
> On 06/29/2015 03:11 PM, Sumit Bose wrote:
> > On Mon, Jun 29, 2015 at 11:24:00AM +0200, Giorgio Biacchi wrote:
> >> On 06/29/2015 10:30 AM, Sumit Bose wrote:
> >>> On Mon, Jun 29, 2015 at 10:04:04AM +0200, Giorgio Biacchi wrote:
> >>>> On 06/26/2015 08:06 PM, Sumit Bose wrote:
> >>>>> On Fri, Jun 26, 2015 at 04:34:05PM +0200, Giorgio Biacchi wrote:
> >>>>>>
> >>>>>>
> >>>>>> On 06/26/2015 02:38 PM, Sumit Bose wrote:
> >>>>>>> On Thu, Jun 25, 2015 at 07:00:34PM +0200, Giorgio Biacchi wrote:
> >>>>>>>> On 06/25/2015 05:44 PM, Sumit Bose wrote:
> >>>>>>>>> On Thu, Jun 25, 2015 at 04:29:37PM +0200, Giorgio Biacchi wrote:
> >>>>>>>>>> On 06/25/2015 02:10 PM, Sumit Bose wrote:
> >>>>>>>>>>> On Thu, Jun 25, 2015 at 01:06:22PM +0200, Giorgio Biacchi wrote:
> >>>>>>>>>>>> On 06/25/2015 12:56 PM, Sumit Bose wrote:
> >>>>>>>>>>>>> On Thu, Jun 25, 2015 at 12:22:16PM +0200, Giorgio Biacchi wrote:
> >>>>>>>>>>>>>> On 06/24/2015 06:45 PM, Sumit Bose wrote:
> >>>>>>>>>>>>>>> On Wed, Jun 24, 2015 at 05:11:07PM +0200, Giorgio Biacchi 
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>> Hi everybody,
> >>>>>>>>>>>>>>>> I established a bidirectional trust between an IPA server 
> >>>>>>>>>>>>>>>> (version 4.1.0 on
> >>>>>>>>>>>>>>>> CentOS 7.1), ipa.mydomain.local and an AD (Windows 2012 r2), 
> >>>>>>>>>>>>>>>> mydomain.local.
> >>>>>>>>>>>>>>>> Everything is working fine, and I'm able to authenticate and 
> >>>>>>>>>>>>>>>> logon on a linux
> >>>>>>>>>>>>>>>> host joined to IPA server using AD credentials 
> >>>>>>>>>>>>>>>> (username@mydomain.local).
> >>>>>>>>>>>>>>>> But active directory is configured with two more UPN 
> >>>>>>>>>>>>>>>> suffixes (otherdomain.com
> >>>>>>>>>>>>>>>> and sub.otherdomain.com), and I cannot logon with 
> >>>>>>>>>>>>>>>> credentials using alternative
> >>>>>>>>>>>>>>>> UPN (example: john@otherdomain.com).
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> How can I make this possible? Another trust (ipa trust-add) 
> >>>>>>>>>>>>>>>> with the same AD?
> >>>>>>>>>>>>>>>> Manual configuration of krb5 and/or sssd?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Have you tried to login to an IPA client or the server? 
> >>>>>>>>>>>>>>> Please try with
> >>>>>>>>>>>>>>> an IPA server first. If this does not work it would be nice 
> >>>>>>>>>>>>>>> if you can
> >>>>>>>>>>>>>>> send the SSSD log files from the IPA server which are 
> >>>>>>>>>>>>>>> generated during
> >>>>>>>>>>>>>>> the logon attempt. Please call 'sss_cache -E' before to 
> >>>>>>>>>>>>>>> invalidate all
> >>>>>>>>>>>>>>> cached entries so that the logs will contain all needed calls 
> >>>>>>>>>>>>>>> to AD.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Using UPN suffixes were added to the AD provider some time 
> >>>>>>>>>>>>>>> ago and the
> >>>>>>>>>>>>>>> code is available in the IPA p

Re: [Freeipa-users] Kerberos hanging approx. once a day

[Sumit Bose]

On Wed, Jul 22, 2015 at 11:06:53AM +0200, Torsten Harenberg wrote:
> Dear community,
> 
> we just moved our infrastructure (about 200 node cluster plus about 30
> workstations) from NIS to FreeIPA (version 4.1.4 on FC 21).
> 
> We have two IPA servers (called "ipa" and "ipa2" both paravirtualized on
> Xen4).
> 
> Approx once a day, the Kerberos service on the primary server suddenly
> stops working and I am unable to re-start the service. Only a "full"
> reboot helps and during that, the Kerberos shutdown takes about 2
> minutes (unsure if it really finishes or if it's the final timeout of
> the shutdown script).
> 
> Trying to collect as many log messages as possible:
> 
> 
> Jul 22 10:52:06 ipa.pleiades.uni-wuppertal.de krb5kdc[1114](info):
> AS_REQ (4 etypes {18 17 16 23}) 132.195.124.213: LOOKING_UP_CLIENT:
> host/proton.pleiades.uni-wuppertal...@pleiades.uni-wuppertal.de for
> krbtgt/pleiades.uni-wuppertal...@pleiades.uni-wuppertal.de, Server error
> Jul 22 10:52:11 ipa.pleiades.uni-wuppertal.de krb5kdc[1114](info):
> AS_REQ (4 etypes {18 17 16 23}) 132.195.125.171: LOOKING_UP_CLIENT:
> host/wn161.pleiades.uni-wuppertal...@pleiades.uni-wuppertal.de for
> krbtgt/pleiades.uni-wuppertal...@pleiades.uni-wuppertal.de, Server error

Looks like there are issues getting the needed data from the local LDAP
server. The message below about the master key points into the same
direction. Can you check the 389ds logs?

bye,
Sumit

> 
> 
> [root@ipa ~]# systemctl status krb5kdc.service
> ● krb5kdc.service - Kerberos 5 KDC
>Loaded: loaded (/usr/lib/systemd/system/krb5kdc.service; disabled)
>Active: failed (Result: exit-code) since Mi 2015-07-22 10:54:22 CEST;
> 10s ago
>   Process: 11910 ExecStart=/usr/sbin/krb5kdc -P /var/run/krb5kdc.pid
> $KRB5KDC_ARGS (code=exited, status=1/FAILURE)
>  Main PID: 1114 (code=exited, status=0/SUCCESS)
> 
> Jul 22 10:54:22 ipa.pleiades.uni-wuppertal.de krb5kdc[11910]: krb5kdc:
> cannot initialize realm PLEIADES.UNI-WUPPERTAL.DE - see log file for details
> Jul 22 10:54:22 ipa.pleiades.uni-wuppertal.de systemd[1]:
> krb5kdc.service: control process exited, code=exited status=1
> Jul 22 10:54:22 ipa.pleiades.uni-wuppertal.de systemd[1]: Failed to
> start Kerberos 5 KDC.
> Jul 22 10:54:22 ipa.pleiades.uni-wuppertal.de systemd[1]: Unit
> krb5kdc.service entered failed state.
> Jul 22 10:54:22 ipa.pleiades.uni-wuppertal.de systemd[1]:
> krb5kdc.service failed.
> [root@ipa ~]# tail -f /var/log/krb5kdc.log
> Jul 22 10:52:11 ipa.pleiades.uni-wuppertal.de krb5kdc[1114](info):
> closing down fd 13
> Jul 22 10:52:11 ipa.pleiades.uni-wuppertal.de krb5kdc[1114](info):
> DISPATCH: repeated (retransmitted?) request from 132.195.124.213,
> resending previous response
> Jul 22 10:52:11 ipa.pleiades.uni-wuppertal.de krb5kdc[1114](info):
> DISPATCH: repeated (retransmitted?) request from 132.195.125.171,
> resending previous response
> Jul 22 10:54:12 ipa.pleiades.uni-wuppertal.de krb5kdc[1114](debug): Got
> signal to request exit
> Jul 22 10:54:12 ipa.pleiades.uni-wuppertal.de krb5kdc[1114](info):
> closing down fd 10
> Jul 22 10:54:12 ipa.pleiades.uni-wuppertal.de krb5kdc[1114](info):
> closing down fd 11
> Jul 22 10:54:12 ipa.pleiades.uni-wuppertal.de krb5kdc[1114](info):
> closing down fd 9
> Jul 22 10:54:12 ipa.pleiades.uni-wuppertal.de krb5kdc[1114](info):
> closing down fd 8
> Jul 22 10:54:12 ipa.pleiades.uni-wuppertal.de krb5kdc[1114](info):
> shutting down
> krb5kdc: Server error - while fetching master key K/M for realm
> PLEIADES.UNI-WUPPERTAL.DE
> 
> 
> [root@ipa ~]# journalctl -xe
> Jul 22 10:53:15 ipa.pleiades.uni-wuppertal.de ntpd[11903]: Listen and
> drop on 1 v6wildcard :: UDP 123
> Jul 22 10:53:15 ipa.pleiades.uni-wuppertal.de ntpd[11903]: Listen
> normally on 2 lo 127.0.0.1 UDP 123
> Jul 22 10:53:15 ipa.pleiades.uni-wuppertal.de ntpd[11903]: Listen
> normally on 3 eth0 132.195.124.12 UDP 123
> Jul 22 10:53:15 ipa.pleiades.uni-wuppertal.de ntpd[11903]: Listen
> normally on 4 lo ::1 UDP 123
> Jul 22 10:53:15 ipa.pleiades.uni-wuppertal.de ntpd[11903]: Listen
> normally on 5 eth0 fe80::216:3eff:fe14:c27a UDP 123
> Jul 22 10:53:15 ipa.pleiades.uni-wuppertal.de ntpd[11903]: Listening on
> routing socket on fd #22 for interface updates
> Jul 22 10:53:15 ipa.pleiades.uni-wuppertal.de systemd[1]: Started
> Network Time Service.
> -- Subject: Unit ntpd.service has finished start-up
> -- Defined-By: systemd
> -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
> --
> -- Unit ntpd.service has finished starting up.
> --
> -- The start-up result is done.
> Jul 22 10:53:15 ipa.pleiades.uni-wuppertal.de ntpd[11903]: 0.0.0.0 c016
> 06 restart
> Jul 22 10:53:15 ipa.pleiades.uni-wuppertal.de ntpd[11903]: 0.0.0.0 c012
> 02 freq_set ntpd -23.557 PPM
> Jul 22 10:53:16 ipa.pleiades.uni-wuppertal.de ntpd[11903]: 0.0.0.0 c615
> 05 clock_sync
> Jul 22 10:54:12 ipa.pleiades.uni-wuppertal.de systemd[1]: Stopping
> Kerberos 5 KDC...
> -- Subject: Unit krb5kdc.service has begun shutting

Re: [Freeipa-users] Kerberos hanging approx. once a day

[Sumit Bose]

On Wed, Jul 22, 2015 at 11:39:25AM +0200, Torsten Harenberg wrote:
> Dear Alexander, dear Sumit,
> 
> thank you very much indeed for the quick replies.
> 
> Am 22.07.15 um 11:21 schrieb Sumit Bose:
> > Looks like there are issues getting the needed data from the local LDAP
> > server. The message below about the master key points into the same
> > direction. Can you check the 389ds logs?
> 
> I have attached the
> /var/log/dirsrv/slapd-PLEIADES-UNI-WUPPERTAL-DE/errors file to the end
> of the mail, it's a bit larger.
> 
> There are some "ticket expired" messages, could that point to the source
> of the problem?
> 
> 
> Am 22.07.15 um 11:22 schrieb Alexander Bokovoy:
> > Do you have 389-ds actually operating? If you would install debuginfo
> > packages, what does 'pstack ' print?
> 
> here is the output:

Thank you for the logs. It looks like the KDC cannot talk to the LDAP
server and the LDAP server cannot talk to the KDC to renew a Kerberos
ticket. So we have to find out which came first. To rule out KDC lookup
issues it would be good if you can send the content for /etc/krb5.conf
and /var/lib/sss/pubconf/kdcinfo.* . Feel free to send it to Alexander
and me by private mail if you do not want to disclose details of your
environment on a public list.

bye,
Sumit

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

Re: [Freeipa-users] Samba Failing to start (Causing FreeIPA to not start!)

[Sumit Bose]

On Wed, Jul 22, 2015 at 11:14:51AM -0700, William Graboyes wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Hi All,
> 
> I have been messing around with AD trust installs mainly around doing
> ntlm_auth for a radius server.
> 
> However, as I was unable to see some of the needed resources, I
> thought maybe IPA may need a kick.
> 
> So I ran the following command
> 
> `ipactl restart`
> 
> # ipactl restart
> Restarting Directory Service
> Restarting krb5kdc Service
> Restarting kadmin Service
> Restarting ipa_memcached Service
> Restarting httpd Service
> Restarting ipa-otpd Service
> Starting smb Service
> Job for smb.service failed. See 'systemctl status smb.service' and
> 'journalctl -xn' for details.
> Failed to start smb Service
> Shutting down
> Aborting ipactl
> 
> # systemctl status smb.service
> smb.service - Samba SMB Daemon
>Loaded: loaded (/usr/lib/systemd/system/smb.service; disabled)
>Active: failed (Result: exit-code) since Wed 2015-07-22 11:01:44
> PDT; 20s ago
>   Process: 16752 ExecStart=/usr/sbin/smbd $SMBDOPTIONS (code=exited,
> status=1/FAILURE)
>  Main PID: 16752 (code=exited, status=1/FAILURE)
>Status: "Starting process..."
>CGroup: /system.slice/smb.service
> 
> Jul 22 11:01:43 ipa-server-1.foo.bar systemd[1]: Starting Samba SMB
> Daemon...
> Jul 22 11:01:43 ipa-server-1.foo.bar smbd[16751]: [2015/07/22
> 11:01:43.956721,  0] ../source3/smbd/server.c:1269(main)
> Jul 22 11:01:44 ipa-server-1.foo.bar smbd[16752]: GSSAPI client step 1
> Jul 22 11:01:44 ipa-server-1.foo.bar smbd[16752]: GSSAPI client step 1
> Jul 22 11:01:44 ipa-server-1.foo.bar smbd[16752]: GSSAPI client step 1
> Jul 22 11:01:44 ipa-server-1.foo.bar smbd[16752]: GSSAPI client step 2
> Jul 22 11:01:44 ipa-server-1.foo.bar systemd[1]: smb.service: main
> process exited, code=exited, status=1/FAILURE
> Jul 22 11:01:44 ipa-server-1.foo.bar systemd[1]: Failed to start Samba
> SMB Daemon.
> Jul 22 11:01:44 ipa-server-1.foo.bar systemd[1]: Unit smb.service
> entered failed state.
> 
> journalctl -xn provides no useful information, however journalctl
> does... sorta:
> 
> Jul 22 11:03:19 ipa-server-1.foo.bar smbd[16903]: [2015/07/22
> 11:03:19.824614,  0] ipa_sam.c:3574(get_fallback_group_sid)
> Jul 22 11:03:19 ipa-server-1.foo.bar smbd[16903]: Missing mandatory
> attribute ipaNTSecurityIdentifier.
> Jul 22 11:03:19 ipa-server-1.foo.bar smbd[16903]: [2015/07/22
> 11:03:19.824829,  0] ipa_sam.c:4526(pdb_init_ipasam)
> Jul 22 11:03:19 ipa-server-1.foo.bar smbd[16903]: Cannot find SID of
> fallback group.
> Jul 22 11:03:19 ipa-server-1.foo.bar smbd[16903]: [2015/07/22
> 11:03:19.824878,  0]
> ../source3/passdb/pdb_interface.c:178(make_pdb_method_name)
> Jul 22 11:03:19 ipa-server-1.foo.bar smbd[16903]: pdb backend
> ipasam:ldapi://%2fvar%2frun%2fslapd-CENIC-ORG.socket did not correctly
> init (error was NT_STATUS_INVALID_PARAMETER)
> Jul 22 11:03:19 ipa-server-1.foo.bar systemd[1]: smb.service: main
> process exited, code=exited, status=1/FAILURE
> Jul 22 11:03:19 ipa-server-1.foo.bar systemd[1]: Failed to start Samba
> SMB Daemon.
> Jul 22 11:03:19 ipa-server-1.foo.bar systemd[1]: Unit smb.service
> entered failed state.

You can try and run 'ipa-adtrust-install' a second time. This might add
all attributes smbd needs.


HTH

bye,
Sumit

> 
> 
> Thanks,
> Bill
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG/MacGPG2 v2
> Comment: GPGTools - https://gpgtools.org
> 
> iQIcBAEBCgAGBQJVr92bAAoJEJFMz73A1+zrgmAQAJp9DXynmqX89gWlacRmS/Hy
> HiwAaiHXmCG7cpWY0PE68l8XgUmpBtOWQJ7hPv83BG1DAyPX267npnFgtJ8t50j7
> mwr9OyuKNiQs0ki4wOnnyNt2xGTgQimugQG0bQsIbP0QBoVAOu6RjK+ucGpagWv8
> zcdIjVP1jjf7I9KtgYzSBT1siFfcP1NAVnd47WC7ombL0db0KIi9oWNy6xXx5rkq
> cSmfonN7jFmkn4gHPzNcqZAIVG+IFJfpqU/OAQrELjkcCXM57BRuzwffnI0DFt6d
> Wm7liuoZHRABlaQ+L9OazCFPGOzpTWKCICdW4Vq6ixpnBG5eRR24Yfqn0z+86R4u
> WmCz2aJEDa2zlZ4IYXZNnIxWkANg+cAxutBKPvyCmQxjxNz9YbPshhQBGG3JVf66
> B3CquNAXNw5O5N/vlKl8RtA4/xArRfvvXtofVrOgRAsjLw2Xdw8tahfIJKptNyYO
> 86CDmyxgoK2ucdncJ5dC8GhX1ajBf5Mu8YnFC7MlfrS72TxsjCBMs5Y5rRmwZwA6
> ZF8TkfaZJmQc/bNe9V/+Ol/qXZM28ZrvZTs68/jTlRlruNc2D9458mdajKxUZB3n
> OaIdE/hXqH7HB32qp9733TCtFxRoJlrD5tVURkHl9kqgnqKxcDZ56VPmNYRn4GYu
> Y7j1+rZUNTtgDUJDk+Jk
> =xQLh
> -END PGP SIGNATURE-
> 
> -- 
> 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

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

Re: [Freeipa-users] Kerberos hanging approx. once a day

[Sumit Bose]

On Thu, Jul 23, 2015 at 08:35:45AM +0200, Torsten Harenberg wrote:
> Huu.. situation is getting worse.
> 
> Even after a full reboot, slapd does not start at all anymore on the
> primary server.
> 
> This is the full log (looks like the realm is missing suddenly?):
> 

...

> [23/Jul/2015:08:25:09 +0200] set_krb5_creds - Could not get initial
> credentials for principal [ldap/ipa@] in keytab [FILE:/etc/krb5.keytab]:
> -1765328164 (Cannot resolve network address for KDC in requested realm)

The principal looks strange, I would at least expect the fully-qualified
name of the ipa server here. What does the 'hostname' command return? It
is expected that it will return the fully-qualified name. Additionally if
you added the ipa server to /etc/hosts please only use the
fully-qualified name to be on the safe side (iirc it is ok to have the
short name as a second name, but the fully-qualified one should be
always first).

The keytab file /etc/krb5.keytab looks strange here. Later on the right
one /etc/dirsrv/ds.keytab is used. Did you try to run the
/usr/sbin/ns-slapd binary manually at some time?

bye,
Sumit

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

Re: [Freeipa-users] Kerberos hanging approx. once a day

[Sumit Bose]

On Thu, Jul 23, 2015 at 09:18:43AM +0200, Torsten Harenberg wrote:
> Hi Sumit,
> 
> 
> > The principal looks strange, I would at least expect the fully-qualified
> > name of the ipa server here. What does the 'hostname' command return? It
> 
> [root@ipa slapd-PLEIADES-UNI-WUPPERTAL-DE]# hostname
> ipa.pleiades.uni-wuppertal.de
> 
> > is expected that it will return the fully-qualified name. Additionally if
> > you added the ipa server to /etc/hosts please only use the
> > fully-qualified name to be on the safe side (iirc it is ok to have the
> > short name as a second name, but the fully-qualified one should be
> > always first).
> 
> I removed the entries vom /etc/hosts again.
> 
> > 
> > The keytab file /etc/krb5.keytab looks strange here. Later on the right
> > one /etc/dirsrv/ds.keytab is used. Did you try to run the
> > /usr/sbin/ns-slapd binary manually at some time?
> >
> 
> Yes.. once .. after it did not came up.
> 
> After another reboot, the system came up now.
> 
> But what I found is
> 
> https://fedorahosted.org/freeipa/ticket/2739
> 
> and indeed:
> 
> [root@ipa slapd-PLEIADES-UNI-WUPPERTAL-DE]# grep WARNING *
> errors:[21/Jul/2015:17:15:21 +0200] - WARNING: cache too small,
> increasing to 500K bytes
> errors:[21/Jul/2015:17:15:21 +0200] - WARNING -- Minimum cache size is
> 512000 -- rounding up
> errors:[21/Jul/2015:17:15:21 +0200] - WARNING -- Minimum cache size is
> 512000 -- rounding up
> errors:[21/Jul/2015:17:15:21 +0200] - WARNING -- Minimum cache size is
> 512000 -- rounding up
> errors:[21/Jul/2015:17:15:21 +0200] - WARNING -- Minimum cache size is
> 512000 -- rounding up
> errors:[21/Jul/2015:17:15:21 +0200] - WARNING -- Minimum cache size is
> 512000 -- rounding up
> errors:[21/Jul/2015:17:15:21 +0200] - WARNING -- Minimum cache size is
> 512000 -- rounding up
> errors:[21/Jul/2015:17:15:21 +0200] - WARNING: userRoot: entry cache
> size 512000B is less than db size 4177920B; We recommend to increase the
> entry cache size nsslapd-cachememsize.
> errors:[21/Jul/2015:17:15:21 +0200] - WARNING: changelog: entry cache
> size 512000B is less than db size 18096128B; We recommend to increase
> the entry cache size nsslapd-cachememsize.
> errors:[22/Jul/2015:11:03:31 +0200] - WARNING -- Minimum cache size is
> 512000 -- rounding up
> errors:[22/Jul/2015:11:03:31 +0200] - WARNING -- Minimum cache size is
> 512000 -- rounding up
> errors:[22/Jul/2015:11:03:31 +0200] - WARNING -- Minimum cache size is
> 512000 -- rounding up
> errors:[22/Jul/2015:11:03:31 +0200] - WARNING -- Minimum cache size is
> 512000 -- rounding up
> errors:[22/Jul/2015:11:03:31 +0200] - WARNING -- Minimum cache size is
> 512000 -- rounding up
> errors:[22/Jul/2015:11:03:31 +0200] - WARNING -- Minimum cache size is
> 512000 -- rounding up
> errors:[22/Jul/2015:11:03:31 +0200] - WARNING: userRoot: entry cache
> size 512000B is less than db size 4218880B; We recommend to increase the
> entry cache size nsslapd-cachememsize.
> errors:[22/Jul/2015:11:03:31 +0200] - WARNING: changelog: entry cache
> size 512000B is less than db size 27992064B; We recommend to increase
> the entry cache size nsslapd-cachememsize.
> errors:[23/Jul/2015:07:33:09 +0200] - WARNING: cache too small,
> increasing to 500K bytes
> errors:[23/Jul/2015:07:33:09 +0200] - WARNING -- Minimum cache size is
> 512000 -- rounding up
> errors:[23/Jul/2015:07:33:09 +0200] - WARNING -- Minimum cache size is
> 512000 -- rounding up
> errors:[23/Jul/2015:07:33:09 +0200] - WARNING -- Minimum cache size is
> 512000 -- rounding up
> errors:[23/Jul/2015:07:33:09 +0200] - WARNING -- Minimum cache size is
> 512000 -- rounding up
> errors:[23/Jul/2015:07:33:09 +0200] - WARNING -- Minimum cache size is
> 512000 -- rounding up
> errors:[23/Jul/2015:07:33:09 +0200] - WARNING -- Minimum cache size is
> 512000 -- rounding up

I'm not a 389ds expert but in my setup nsslapd-cachememsize is set to
10M and since I didn't do any tuning I would expect that this is some
default.

> 
> 
> And what I see is that nodes occasionaly loose their users. I haven't
> seen that the two month while testing (of course there were no real
> users during that time, so I'm not 100% sure that it did not happen).
> 
> Could that be the cause of the trouble??

The users and groups are delivered to the system via SSSD. If SSSD loses
the connection to the IPA servers, e.g. because the server does not
respond, SSSD cannot lookup new users. Nevertheless SSSD has a cache and
users and groups are delivered from the cache in this case. But system
users which important for the services to run like the users dirsrv,
apache, pkiuser etc are defined in /etc/passwd. So I don't expect this
to bethe casue of the trouble.

bye,
Sumit

> 
> Kind regards,
> 
>   Torsten
> 
> 
> 
> -- 
> <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
> <>  <>
> <> Dr. Torsten Harenberg harenb...@physik.uni-wuppertal.de  <>
> <> Bergische Universitaet   

Re: [Freeipa-users] Kerberos hanging approx. once a day

[Sumit Bose]

On Thu, Jul 23, 2015 at 10:21:41AM +0200, Marisa Sandhoff wrote:
> Hi Sumit,
> 
> > 
> > I'm not a 389ds expert but in my setup nsslapd-cachememsize is set to
> > 10M and since I didn't do any tuning I would expect that this is some
> > default.
> > 
> 
> Perhaps we should start with increasing the nsslapd-cachememsize to 10M
> and than see what happens with our server. Actually, how can we increase
> this cachmemsize?

Does
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Performance_Tuning_Guide/memoryusage.html
help?

bye,
Sumit

> 
> Thanks for your help,
> Torsten and Marisa
> 
> -- 
> Dr. Marisa Sandhoff
> Experimentelle Elementarteilchenphysik
> Fachbereich C - Physik
> Bergische Universitaet Wuppertal
> Gaussstr. 20
> D-42097 Wuppertal, Germany
> ---
> marisa.sandh...@cern.ch
> sandh...@physik.uni-wuppertal.de
> Phone +49 202 439 3521
> Fax   +49 202 439 2811
> 
> -- 
> 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

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

Re: [Freeipa-users] Setting up Active Directory trusts in a secure environment

[Sumit Bose]

On Thu, Jul 30, 2015 at 05:35:53PM -0500, Dan Mossor wrote:
> Greetings, folks.
> 
> So, I've been fighting with getting a trust set up between FreeIPA 4.1 on
> CentOS 7.1 and Windows Server 2008r2 for nearly a week. Today I finally came
> to a conclusion as to what my issue is.
> 
> I operate a secure network in which we have configuration guidlines for
> securing Windows that we have to meet in order to recieve what's known as an
> "Authority to Operate", or ATO. A lot of this configuration is done in the
> Global Policies.
> 
> Today I stumbled across one error buried in the Windows Security event log,
> and when correllated with the errors I was seeing from FreeIPA led me to our
> policy. The error that popped up in the event log was "The user has not been
> granted the requested logon type at this machine." The logon type was "3",
> which is network, and the Logon Process and Authorization Package were both
> Kerberos.
> 
> Cross referenced with the error on the IPA server:
> "WARNING: Search on AD DC WINSRV.ad.domain.net:3268 failed with:
> Insufficient access: 8009030C: LdapErr: DSID-0C0904DC, comment:
> AcceptSecurityContext error, data 569, v1db1 Invalid Credentials"
> 
> Digging into our Domain Controller policy, I found that "Access this
> computer from the network" is restricted to Domain Users, Domain
> Controllers, Domain Computers, Domain Admins, and BUILTIN\Administrators. I
> attempted to add a context that would allow the IPA server to log on, and
> got so far through the wizard that it let me select the trusted domain to
> search and returned a list of security contexts, but when I attempted to add
> one (Authenticated Users), I recieved the error that it couldn't be found
> because the server was inaccessable. I saw no errors on the IPA side during
> this transaction.

Thank you for the detailed analysis. I guess the 'server was
inaccessible' error is due to the fact that currently FreeIPA does not
have a global catalog, because Windows typically tries to get SIDs from
remote objects from the Global Catalog.

> 
> So, to those of y'all that operate in secure environments, what trick do you
> use to fully integrate IPA and Active Directory?

With FreeIPA-4.2 the one-way trust feature is introduced. The main
difference to the current scheme is that with one-way trust the FreeIPA
server does not use its host credentials (host keytab) from the IPA
domain to access the AD DC but uses the trusted domain user
(IPADOM$@AD.DOMAIN) to access the AD DC. Since this is an object from
the AD domain it should be possible to assign the needed permissions to
this object.

Currently I have no idea how this can be solved with older version.
Maybe there is a toll on the Windows side which lets you add SIDs
manually into the "Access this computer from the network" policy? If
there is one you can try to add IPA-SID-515 (where you have to replace
IPA-SID by the IPA domain SID).

HTH

bye,
Sumit

> 
> -- 
> Dan Mossor, RHCSA
> Systems Engineer
> Fedora Server WG | Fedora KDE WG | Fedora QA Team
> Fedora Infrastructure Apprentice
> FAS: dmossor IRC: danofsatx
> San Antonio, Texas, USA
> 
> -- 
> 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

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

Re: [Freeipa-users] Setting up Active Directory trusts in a secure environment

[Sumit Bose]

On Fri, Jul 31, 2015 at 09:23:53AM -0500, Dan Mossor wrote:
> On 07/31/2015 02:52 AM, Sumit Bose wrote:
> >
> >Thank you for the detailed analysis. I guess the 'server was
> >inaccessible' error is due to the fact that currently FreeIPA does not
> >have a global catalog, because Windows typically tries to get SIDs from
> >remote objects from the Global Catalog.
> >
> >>
> >>So, to those of y'all that operate in secure environments, what trick do you
> >>use to fully integrate IPA and Active Directory?
> >
> >With FreeIPA-4.2 the one-way trust feature is introduced. The main
> >difference to the current scheme is that with one-way trust the FreeIPA
> >server does not use its host credentials (host keytab) from the IPA
> >domain to access the AD DC but uses the trusted domain user
> >(IPADOM$@AD.DOMAIN) to access the AD DC. Since this is an object from
> >the AD domain it should be possible to assign the needed permissions to
> >this object.
> >
> >Currently I have no idea how this can be solved with older version.
> >Maybe there is a toll on the Windows side which lets you add SIDs
> >manually into the "Access this computer from the network" policy? If
> >there is one you can try to add IPA-SID-515 (where you have to replace
> >IPA-SID by the IPA domain SID).
> >
> >HTH
> >
> >bye,
> >Sumit
> >
> 
> I didn't think the SID was even being evaluated - the authentication being
> attempted was through Kerberos, which I uderstand only uses host keytabs,
> not SIDs. Am I correct in this situation?

yes and no :-) The keytab is used to get a TGT and then a cross-realm
TGT from the IPA KDC. The IPA KDC will add a PAC to the TGTs which
contains additional authorization data including SIDs. The PAC is then
used on the Windows side to evaluate if access is granted or not.

bye,
Sumit

> 
> Dan
> 
> -- 
> Dan Mossor, RHCSA
> Systems Engineer
> Fedora Server WG | Fedora KDE WG | Fedora QA Team
> Fedora Infrastructure Apprentice
> FAS: dmossor IRC: danofsatx
> San Antonio, Texas, USA

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

Re: [Freeipa-users] ssh_exchange_identification: Connection closed by remote host

[Sumit Bose]

On Fri, Aug 28, 2015 at 05:10:31PM +0200, Roberto Cornacchia wrote:
> Hi,
> 
> I have two hosts, "photon" and "hadron", and an LDAP user "roberto".
> The user can login successfully on both machines.
> 
> The SSH pub key is uploaded
> .
> Running "sss_ssh_authorizedkeys roberto" from both clients returns the same
> key.
> 
> Port 22 is open on both clients, sshd is running on both clients.
> 
> On both client, /etc/ssh/ssh_config is:
> Host *
> GlobalKnownHostsFile /var/lib/sss/pubconf/known_hosts
> PubkeyAuthentication yes
> ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h
> GSSAPIAuthentication yes
> 
> On both clients, /etc/ssh/sshs_config is:
> KerberosAuthentication no
> PubkeyAuthentication yes
> UsePAM yes
> AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
> GSSAPIAuthentication yes
> AuthorizedKeysCommandUser nobody
> 
> 
> However, ssh from hadron to photon works, the other way around doesn't:
> 
> roberto@photon $ ssh -vv hadron
> OpenSSH_6.9p1, OpenSSL 1.0.1k-fips 8 Jan 2015
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: /etc/ssh/ssh_config line 56: Applying options for *
> debug1: Executing proxy command: exec /usr/bin/sss_ssh_knownhostsproxy -p
> 22 hadron
> debug1: permanently_drop_suid: 117206
> debug1: identity file /home/roberto/.ssh/id_rsa type 1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/roberto/.ssh/id_rsa-cert type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/roberto/.ssh/id_dsa type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/roberto/.ssh/id_dsa-cert type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/roberto/.ssh/id_ecdsa type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/roberto/.ssh/id_ecdsa-cert type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/roberto/.ssh/id_ed25519 type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/roberto/.ssh/id_ed25519-cert type -1
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_6.9
> *ssh_exchange_identification: Connection closed by remote host*
> 
> 
> If I include a few other cases, this is the summary:
> - photon to hadron FAILS
> - photon to photon SUCCEEDS
> - photon to ipa server SUCCEEDS
> - photon to (non-ipa-client) FAILS before asking password (no keypair
> suthentication expected here)
> 
> - hadron to photon SUCCEEDS
> - hadron to hadron FAILS
> - hadron to ipa server SUCCEEDS
> - hadron to (non-ipa-client) FAILS before asking password (no keypair
> suthentication expected here)
> 
> I know that the error above is quite generic, so I don't expect someone can
> point out the exact cause, but perhaps someone can help me debug this? What
> could I look at?

Do you have any HBAC rules for hadron activated on the IPA server?

If not, can you activate sshd debug logging on hadron by setting
LogLevel to DEBUG3 in sshd_config and restarting sshd? Maybe they have
some useful information.

HTH

bye,
Sumit

> 
> Thanks,
> Roberto

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

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

Re: [Freeipa-users] different EMail Addresses

[Sumit Bose]

On Sun, Aug 30, 2015 at 09:29:31PM +0300, Alexander Bokovoy wrote:
> On Sun, 30 Aug 2015, Günther J. Niederwimmer wrote:
> >Hello,
> >
> >what is the way to read a different EMail Address from freeIPA?
> >
> >My system is a centos 7
> >
> >When I create a user "joe", on a system like ipa.example.com  ldap
> >dc=example, dc=com kerberos=EXAMPLE.COM. I have in the "mask" from
> >the user, a default EMail Address "j...@example.com", but the user must
> >have also a secondary EMail address like joe@other_domain.net, it is no
> >problem to insert this address, but I can't never read / found this address
> >with sssd ?
> SSSD reports POSIX attributes of the user, the same you find in
> /etc/passwd, see details in
>  info libc 'user database' 'user data structure'
> 
> This information does not include email address for users, so SSSD does
> not return it.
> 
> Where are you going to consume the email information?

If a D-Bus interface can be used you can find details how to tell SSSD
to read extra attributes form an LDAP server and make them available via
D-Bus on http://adam.younglogic.com/2014/05/mod_lookup_identity/ .

HTH

bye,
Sumit

> 
> -- 
> / Alexander Bokovoy
> 
> -- 
> 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

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

Re: [Freeipa-users] Using SSH from Active Directory machines for FreeIPA clients with kerberos tickets

[Sumit Bose]

On Mon, Sep 14, 2015 at 09:24:15AM +0200, Morgan Marodin wrote:
> The Pro edition.
> 
> I've solved my connection problem, I have to specify manually the username (
> name.surname@ad_domain.com) with Microsoft SSPI.
> In this mode is ok, but using Putty "Use system username" do not works for
> me.

iirc putty strips the domain part '@ad_domain.com' here and only uses
'name.surname' to log into a client. Since by default we require a
fully-qualified name which include to domain part to avoid ambiguity the
login fails.

HTH

bye,
Sumit

> 
> 
> I don't know why :)
> Bye, Morgan
> 
> 2015-09-11 22:24 GMT+02:00 Alexander Bokovoy :
> 
> > On Fri, 11 Sep 2015, Morgan Marodin wrote:
> >
> >> Hi everyone.
> >>
> >> I've seen these guides:
> >>
> >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/trust-ssh.html
> >>
> >> https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/trust-ssh.html
> >>
> >> https://www.dalemacartney.com/2013/08/30/single-sign-on-sso-with-secure-shell-ssh/
> >>
> >> But I've not been able to access via ssh to a freeipa client with kerberos
> >> tickets.
> >> I've also tried to install MIT kerberos to my windows 8.1, but doesn't
> >> works too.
> >>
> > This is not required.
> >
> > What Windows 8.1 version you have? Is it a Pro edition (the other
> > editions don't join AD)?
> >
> > The target freeipa client is a RHEL 6.7 like distribution.
> >>
> >> Naturally trying with AD username (name.surn...@mydomain.com) and
> >> password
> >> is ok.
> >>
> >> Do you have any suggestions for this problem?
> >>
> > Enable DEBUG3 level logging in sshd_config for SSH server, attempt to
> > login from Windows client and show the logs around 'userok' in the
> > resulting debug output.
> >
> > --
> > / Alexander Bokovoy
> >
> 
> 
> 
> -- 
> Morgan Marodin
> email: mor...@marodin.it
> mobile: +39.3477829069

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

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

Re: [Freeipa-users] Using SSH from Active Directory machines for FreeIPA clients with kerberos tickets

[Sumit Bose]

On Mon, Sep 14, 2015 at 11:16:57AM +0200, Morgan Marodin wrote:
> Ok, but now I've an other problem :)
> 
> If I disable the default allow_all HBAC rule creating one custom HBAC rule
> that enable ad_admins to access any host any service, kerberos ticket via
> ssh does not works.
> Username/password authentication with the same custom HBAC rules works.
> 
> SSH logs with kerberos authentication:
> Sep 14 11:04:43 ipa-client01 sshd[1728]: Authorized to
> administra...@mydomain.com, krb5 principal administra...@mydomain.com
> (krb5_kuserok)
> Sep 14 11:04:43 ipa-client01 sshd[1728]: pam_sss(sshd:account): Access
> denied for user administra...@mydomain.com: 6 (Permission denied)
> Sep 14 11:04:43 ipa-client01 sshd[1729]: fatal: Access denied for user
> administra...@mydomain.com by PAM account configuration
> 
> SSH logs with username/password authentication:
> Sep 14 11:10:30 ipa-client01 sshd[1766]: pam_unix(sshd:auth):
> authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
> rhost=192.168.0.252  user=administra...@mydomain.com
> Sep 14 11:10:31 ipa-client01 sshd[1766]: pam_sss(sshd:auth): authentication
> success; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.252 user=
> administra...@mydomain.com
> Sep 14 11:10:31 ipa-client01 sshd[1766]: Accepted password for
> administra...@mydomain.com from 192.168.0.252 port 49590 ssh2
> Sep 14 11:10:31 ipa-client01 sshd[1766]: pam_unix(sshd:session): session
> opened for user administra...@mydomain.com by (uid=0)
> 
> If I enable allow_all HBAC rule kerberos authentication works.
> Maybe is there something else to configure?

no, HBAC result should not change depending on the authentication
method. Can you send me the SSSD logs with a high debug level (10) for
both cases? If you prefer you can send them to me directly.

bye,
Sumit

> 
> Thanks, Morgan
> 
> 2015-09-14 9:48 GMT+02:00 Alexander Bokovoy :
> 
> > On Mon, 14 Sep 2015, Morgan Marodin wrote:
> >
> >> The Pro edition.
> >>
> >> I've solved my connection problem, I have to specify manually the
> >> username (
> >> name.surname@ad_domain.com) with Microsoft SSPI.
> >> In this mode is ok, but using Putty "Use system username" do not works for
> >> me.
> >>
> >>
> >> I don't know why :)
> >>
> > A problem is in the fact that when you use PuTTY's 'use system
> > username', it does only provide unqualified name there, e.g.
> > Administrator, not AD\Administrator or administra...@ad.test. On IPA
> > client side AD users are fully qualified and thus a user you are trying
> > to login to (Administrator) is not the same as the user you are
> > (adminsitra...@ad.test).
> > --
> > / Alexander Bokovoy
> >
> 
> 
> 
> -- 
> Morgan Marodin
> email: mor...@marodin.it
> mobile: +39.3477829069

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

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

Re: [Freeipa-users] ssh and sudo password authentication not working with freeipa-client 3.3.4-0ubuntu3.1 on Ubuntu 14.04

[Sumit Bose]

On Fri, Oct 02, 2015 at 04:28:57PM +0200, Alexander Skwar wrote:
> Hello
> 
> How do I get password authentication to work with freeipa-client
> 3.3.4-0ubuntu3.1 on Ubuntu 14.04 for ssh and sudo?
> 
> Long version follows :)
> 
> We've got an IPA server with the Red Hat Identity Management server
> on RHEL 7.1 servers; FreeIPA v4.1.0 is being used there. I configured
> users and groups there and would now like to login with SSH. When I
> store a SSH key for the user account, I can login just fine, using
> this SSH key. But I'd like/need to use passwords as well. And sudo
> also doesn't work, when it's asking for passwords - I supposed,
> it's the same root cause.
> 
> Let's stick with SSH.
> 
> Initially, I installed the FreeIPA client with this command line:
> 
> ipa-client-install --force-join --mkhomedir --ssh-trust-dns \
>   --enable-dns-updates --unattended \
>   --principal=admin --password=correctone \
>   --domain=customer.company.internal \
>   --server=auth01.customer.company.internal
> 
> I then try to do a SSH login with:
> 
> ssh -l ewt@customer.company.internal 192.168.229.143
> or:
> ssh -l ewt 192.168.229.143
> 
> Password authentication doesn't work.
> 
> In the /var/log/syslog on the system where I try to login, I find this:
> 
> 2015-10-02T15:33:38.771291+02:00 mgmt02 [sssd[krb5_child[14154]]]:
> Key table entry not found
> 
> After having turned up the debug level of the sssd with "sssd -i -f -d
> 0x0770 --debug-timestamps=1", I find the following in the system log
> files:
> 
> 2015-10-02T15:40:48.756399+02:00 mgmt02 sshd[14194]:
> pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0
> tty=ssh ruser= rhost=212.71.117.1  user=ewt
> 2015-10-02T15:40:48.775896+02:00 mgmt02 sshd[14194]:
> pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0
> tty=ssh ruser= rhost=212.71.117.1 user=ewt
> 2015-10-02T15:40:48.775927+02:00 mgmt02 sshd[14194]:
> pam_sss(sshd:auth): received for user ewt: 4 (System error)
> 2015-10-02T15:40:50.988591+02:00 mgmt02 sshd[14194]: Failed
> password for ewt from 212.71.117.1 port 58136 ssh2
> 
> TBH, I don't quite understand it. Anyway, in
> /var/log/sssd/sssd_customer.company.internal.log I noticed:
> 
> (Fri Oct  2 15:46:26 2015) [sssd[be[customer.company.internal]]]
> [read_pipe_handler] (0x0400): EOF received, client finished
> (Fri Oct  2 15:46:26 2015) [sssd[be[customer.company.internal]]]
> [parse_krb5_child_response] (0x0020): message too short.
> (Fri Oct  2 15:46:26 2015) [sssd[be[customer.company.internal]]]
> [krb5_auth_done] (0x0040): Could not parse child response [22]:
> Invalid argument
> (Fri Oct  2 15:46:26 2015) [sssd[be[customer.company.internal]]]
> [ipa_auth_handler_done] (0x0040): krb5_auth_recv request failed.

looks like krb5_child is not able to process the request. There should
be a krb5_child log as well, maybe it has more details.

bye,
Sumit

> 
> Well… What am I doing wrong or what might I have forgotten?
> 
> Thanks a lot and best regards,
> 
> Alexander
> -- 
> =>Google+ => http://plus.skwar.me <==
> => Chat (Jabber/Google Talk) => a.sk...@gmail.com <==
> 
> -- 
> 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

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

Re: [Freeipa-users] FreeOTP

[Sumit Bose]

On Thu, Jun 16, 2016 at 10:28:41AM +0200, Winfried de Heiden wrote:
> Hi all,
> 
> "So it looks a bit like a libverto 32bit issue"; any news or progress on
> this? Bugzilla?

sorry for the delay, but I'm currently busy with other items. I can come
back to you on this issue early next week.

Btw, so far I would say it is an issue in libkrad.

bye,
Sumit

> 
> Winny
> 
> 
> Op 09-06-16 om 18:51 schreef Sumit Bose:
> > On Thu, Jun 09, 2016 at 08:42:59AM -0400, Nathaniel McCallum wrote:
> > > On Thu, 2016-06-09 at 10:46 +0200, Sumit Bose wrote:
> > > > On Thu, Jun 09, 2016 at 08:16:13AM +0200, Winfried de Heiden wrote:
> > > > > Hi all,
> > > > > 
> > > > > I can install libvert-libev but removing libverto-tevent will
> > > > > remove 123
> > > > > dependencies also. (wget, tomcat and much more...)
> > > > > 
> > > > > Hence, I installed libverto-libev, but dit not remove libverto-
> > > > > tevent to give
> > > > > it a try. After ipactl restart still the same problem:
> > > > fyi, I think I can reproduce the issue on 32bit Fedora. I tried
> > > > libverto-libev as well but I removed libverto-tevent after installing
> > > > libverto-libev with 'rpm -e --nodeps ' to make sure libverto has
> > > > no
> > > > other chance.
> > > > 
> > > > So it looks a bit like a libverto 32bit issue. I used
> > > > libverto-0.2.6-4.fc22. Since I knew that is was working before on
> > > > 32bits
> > > > I tried libverto-0.2.5 and libverto-0.2.4 as well with no lock.
> > > > 
> > > > Nathaniel, do you have any suggestions what to check with gdb?
> > > It may not be a libverto issue at all. Just to summarize, krb5kdc sends
> > > the otp request to ipa-otpd using RADIUS-over-UNIX-socket.
> > > 
> > > It appears that ipa-otpd receives the request and sends the appropriate
> > > response. However, krb5kdc never appears to receive the request and
> > > times out. Once it times out, it closes the socket and ipa-otpd exits.
> > > 
> > > The question is: why?
> > > 
> > > This could be a bug in krb5kdc, libkrad or libverto. Does the event
> > > actually fire from libverto? Does libkrad process it correctly? Does
> > > krb5kdc process it correctly?
> > > 
> > > There are lots of places to attach gdb. I would probably start here:
> > > https://github.com/krb5/krb5/blob/master/src/lib/krad/client.c#L193
> > It looks like the 3rd argument of recv(), the buffer length, becomes
> > negative aka very big in on_io_read()
> > 
> >  i = recv(verto_get_fd(rr->io), rr->buffer.data + rr->buffer.length,
> >   pktlen - rr->buffer.length, 0);
> > 
> > because pktlen is 4 and rr->buffer.length is 16 on my 32bit system. I
> > wonder if pktlen isn't sufficient here because it already is the result
> > of 'len - buffer->length' which is calculated in
> > krad_packet_bytes_needed() ?
> > 
> > bye,
> > Sumit
> > 
> 

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

Re: [Freeipa-users] Ghost ipaSshPubKey in sss_ssh_authorizedkeys or 'Error looking up public keys'

[Sumit Bose]

On Mon, Jun 20, 2016 at 10:46:13PM +0200, Martin Štefany wrote:
> Hello all,
> 
> I've ran into strange issue with IPA/SSSD/SSH/SELinux which started when I
> figured out that I cannot ssh with pubkey auth to Fedora 23 (ipa-client) 
> systems
> while I can to CentOS 7.2 (ipa-client and ipa-server) systems within same IPA
> domain. I will appreciate any help whatsoever.
> IPA servers (and most of the clients) are IPA 4.2.0 on CentOS 7.2 with latest
> updates, affected clients are IPA clients 4.2.4 on Fedora 23 with latest
> updates.
> 
> I started by looking to the journal:
> jún 20 13:02:50 desk2.stefany.eu sshd[25162]: Connection
> from 144.xxx.xxx.xxx port 22543 on 172.17.100.191 port 22
> ...
> jún 20 13:02:56 desk2.stefany.eu audit[23328]: AVC avc:  denied  { 
> name_connect
> } for  pid=23328 comm="sssd_ssh" dest=80 scontext=system_u:system_r:sssd_t:s0
> tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket permissive=0
> jún 20 13:02:56 desk2.stefany.eu audit[23328]: SYSCALL arch=c03e 
> syscall=42
> success=no exit=-13 a0=15 a1=7fff145c35b0 a2=10 a3=5614dbbe2a50 items=0
> ppid=23316 pid=23328 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
> sgid=0 

Does the user by chance have a certificate added to his entry including
a link to an OCSP responder?

Recent version of SSSD have the ability to generate public ssh-keys from
valid certificates added to the user entry to support the ssh Smartcard
feature (see e.g. the -I option in the ssh man page for details or
https://fedorahosted.org/sssd/wiki/DesignDocs/SmartcardAuthenticationStep1#RunningsshclientwithSmartcardsupport)

While trying to validate thecertificate via OCSP sssd_ssh must connect
to a http server. To allow this setting the 'nis_enabled' SELinux
boolean to true should help.

Nevertheless, since this should work by default, it would be nice if you
can open a bugzilla ticket for the SELinux policy on F23 to allow this
by default.

HTH

bye,
Sumit

> ...
> jún 20 13:02:56 desk2.stefany.eu audit[23328]: AVC avc:  denied  { 
> name_connect
> } for  pid=23328 comm="sssd_ssh" dest=80 scontext=system_u:system_r:sssd_t:s0
> tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket permissive=0
> jún 20 13:02:56 desk2.stefany.eu audit[23328]: SYSCALL arch=c03e 
> syscall=42
> success=no exit=-13 a0=15 a1=7fff145c35b0 a2=10 a3=5614dbbe42d0 items=0
> ppid=23316 pid=23328 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
> sgid=0 
> ...
> jún 20 13:02:56 desk2.stefany.eu sshd[25162]: error: AuthorizedKeysCommand
> /usr/bin/sss_ssh_authorizedkeys martin failed, status 1
> ...
> jún 20 13:02:56 desk2.stefany.eu sshd[25162]: Failed publickey for martin
> from 144.xxx.xxx.xxx port 22543 ssh2: RSA SHA256:uyzB4[stripped]
> ...
> jún 20 13:02:56 desk2.stefany.eu sshd[25162]: error: Received disconnect
> from 144.xxx.xxx.xxx port 22543:14: No supported authentication methods
> available [preauth]
> jún 20 13:02:56 desk2.stefany.eu sshd[25162]: Disconnected from 
> 144.xxx.xxx.xxx
> port 22543 [preauth]
> 
> which was weird, because the same key would nicely work elsewhere (on any 
> other
> CentOS 7.2 system, while no Fedora 23 system would work as I have figured out)
> 
> I have tried putting SELinux into permissive mode, or generating custom module
> with custom policy allowing this, but it doesn't help, and even tcpdump 
> capture
> doesn't capture anything when such connection to 'somewhere' port 80 is 
> opened.
> 
> I moved on to testing the '/usr/bin/sss_ssh_authorizedkeys martin' command.
> Fedora 23:
> # sss_ssh_authorizedkeys martin
> Error looking up public keys
> 
> CentOS 7.2:
> # sss_ssh_authorizedkeys martin
> ssh-rsa AAA...
> ssh-rsa AAA...
> ssh-ed25519 AAA...
> ssh-rsa AAA...
> ssh-rsa B3NzaC1yc2EDAQABAAABAQCsox... (???) -->> this is one is not in
> LDAP (checked with ldapsearch & ipa user-show martin --all --raw), not present
> in dc=stefany,dc=eu tree or in compat tree
> 
> So, I have turned on debug_level = 0x0250 in sssd.conf in both Fedora 23 and
> CentOS 7.2 and checked the logs. CentOS 7.2 is just fine, Fedora 23 gives 
> these
> failures:
> ==> /var/log/sssd/sssd_ssh.log <==
> (Mon Jun 20 21:58:14 2016) [sssd[ssh]] [sss_cmd_get_version] (0x0200): 
> Received
> client version [0].
> (Mon Jun 20 21:58:14 2016) [sssd[ssh]] [sss_cmd_get_version] (0x0200): Offered
> version [0].
> (Mon Jun 20 21:58:14 2016) [sssd[ssh]] [sss_parse_name_for_domains] (0x0200):
> name 'martin' matched without domain, user is martin
> 
> ==> /var/log/sssd/sssd_stefany.eu.log <==
> (Mon Jun 20 21:58:14 2016) [sssd[be[stefany.eu]]] [be_get_account_info]
> (0x0200): Got request for [0x1][BE_REQ_USER][1][name=martin]
> 
> ==> /var/log/sssd/sssd_ssh.log <==
> (Mon Jun 20 21:58:14 2016) [sssd[ssh]] [decode_and_add_base64_data] (0x0040):
> cert_to_ssh_key failed.
> (Mon Jun 20 21:58:14 2016) [sssd[ssh]] [ssh_cmd_build_reply] (0x0040):
> decode_and_add_base64_data failed.
> 
> And that's right, the last - ghost - "sshpubkey" is in

Re: [Freeipa-users] Ghost ipaSshPubKey in sss_ssh_authorizedkeys or 'Error looking up public keys'

[Sumit Bose]

On Tue, Jun 21, 2016 at 12:43:23PM +0200, Martin Štefany wrote:
> Hello Sumit,
> 
> putting SELinux to permissive mode and/or enabling nis_enabled seboolean
> seemed not help at all. And you are right, my user has userCertificate
> (needed for secure libvirtd connection).
> 
> 
> [martin@desk2 ~]$ sss_ssh_authorizedkeys  martin
> Error looking up public keys
> [martin@desk2 ~]$ sudo setenforce 0
> [sudo] password for martin:
> [martin@desk2 ~]$ sss_ssh_authorizedkeys  martin
> Error looking up public keys
> [martin@desk2 ~]$ sudo setsebool nis_enabled on
> [martin@desk2 ~]$ sss_ssh_authorizedkeys  martin
> Error looking up public keys
> [martin@desk2 ~]$ sudo sss_cache -E
> [martin@desk2 ~]$ sss_ssh_authorizedkeys martin
> Error looking up public keys
> 
> [have a coffee... really]
> 
> [martin@desk2 ~]$ sss_ssh_authorizedkeys martin
> ssh-rsa AAA...
> ssh-rsa AAA...
> ssh-ed25519 AAA...
> ssh-rsa AAA...
> ssh-rsa AAA...

If I understand it correctly you get the same result as on CentOS,
including the unexpected key derived from the certificate, after waiting
for some time? Can you send the sssd_ssh.log with the sequence from
above (if you prefer directly to me) so that I can check why it failed
in the first attempt and later succeeds.

bye,
Sumit

> 
> 
> RH bug for selinux-policy:
> https://bugzilla.redhat.com/show_bug.cgi?id=1348447
> 
> Thank you!
> Martin
> 
> 
> On 6/21/2016 9:43 AM, Sumit Bose wrote:
> > On Mon, Jun 20, 2016 at 10:46:13PM +0200, Martin Štefany wrote:
> > > Hello all,
> > > 
> > > I've ran into strange issue with IPA/SSSD/SSH/SELinux which started when I
> > > figured out that I cannot ssh with pubkey auth to Fedora 23 (ipa-client) 
> > > systems
> > > while I can to CentOS 7.2 (ipa-client and ipa-server) systems within same 
> > > IPA
> > > domain. I will appreciate any help whatsoever.
> > > IPA servers (and most of the clients) are IPA 4.2.0 on CentOS 7.2 with 
> > > latest
> > > updates, affected clients are IPA clients 4.2.4 on Fedora 23 with latest
> > > updates.
> > > 
> > > I started by looking to the journal:
> > > jún 20 13:02:50 desk2.stefany.eu sshd[25162]: Connection
> > > from 144.xxx.xxx.xxx port 22543 on 172.17.100.191 port 22
> > > ...
> > > jún 20 13:02:56 desk2.stefany.eu audit[23328]: AVC avc:  denied  { 
> > > name_connect
> > > } for  pid=23328 comm="sssd_ssh" dest=80 
> > > scontext=system_u:system_r:sssd_t:s0
> > > tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket permissive=0
> > > jún 20 13:02:56 desk2.stefany.eu audit[23328]: SYSCALL arch=c03e 
> > > syscall=42
> > > success=no exit=-13 a0=15 a1=7fff145c35b0 a2=10 a3=5614dbbe2a50 items=0
> > > ppid=23316 pid=23328 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 
> > > egid=0
> > > sgid=0
> > 
> > Does the user by chance have a certificate added to his entry including
> > a link to an OCSP responder?
> > 
> > Recent version of SSSD have the ability to generate public ssh-keys from
> > valid certificates added to the user entry to support the ssh Smartcard
> > feature (see e.g. the -I option in the ssh man page for details or
> > https://fedorahosted.org/sssd/wiki/DesignDocs/SmartcardAuthenticationStep1#RunningsshclientwithSmartcardsupport)
> > 
> > While trying to validate thecertificate via OCSP sssd_ssh must connect
> > to a http server. To allow this setting the 'nis_enabled' SELinux
> > boolean to true should help.
> > 
> > Nevertheless, since this should work by default, it would be nice if you
> > can open a bugzilla ticket for the SELinux policy on F23 to allow this
> > by default.
> > 
> > HTH
> > 
> > bye,
> > Sumit
> > 
> > > ...
> > > jún 20 13:02:56 desk2.stefany.eu audit[23328]: AVC avc:  denied  { 
> > > name_connect
> > > } for  pid=23328 comm="sssd_ssh" dest=80 
> > > scontext=system_u:system_r:sssd_t:s0
> > > tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket permissive=0
> > > jún 20 13:02:56 desk2.stefany.eu audit[23328]: SYSCALL arch=c03e 
> > > syscall=42
> > > success=no exit=-13 a0=15 a1=7fff145c35b0 a2=10 a3=5614dbbe42d0 items=0
> > > ppid=23316 pid=23328 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 
> > > egid=0
> > > sgid=0
> > > ...
> > > jún 20 13:02:56 desk2.stefany.eu sshd[25162]: error: AuthorizedKeysCommand
> > > /usr/bin/sss_ssh_authorizedkeys martin failed, status 1
> > &

Re: [Freeipa-users] Ghost ipaSshPubKey in sss_ssh_authorizedkeys or 'Error looking up public keys'

[Sumit Bose]

On Tue, Jun 21, 2016 at 01:23:11PM +0200, Martin Štefany wrote:
> On 6/21/2016 1:16 PM, Sumit Bose wrote:
> > On Tue, Jun 21, 2016 at 12:43:23PM +0200, Martin Štefany wrote:
> > > Hello Sumit,
> > > 
> > > putting SELinux to permissive mode and/or enabling nis_enabled seboolean
> > > seemed not help at all. And you are right, my user has userCertificate
> > > (needed for secure libvirtd connection).
> > > 
> > > 
> > > [martin@desk2 ~]$ sss_ssh_authorizedkeys  martin
> > > Error looking up public keys
> > > [martin@desk2 ~]$ sudo setenforce 0
> > > [sudo] password for martin:
> > > [martin@desk2 ~]$ sss_ssh_authorizedkeys  martin
> > > Error looking up public keys
> > > [martin@desk2 ~]$ sudo setsebool nis_enabled on
> > > [martin@desk2 ~]$ sss_ssh_authorizedkeys  martin
> > > Error looking up public keys
> > > [martin@desk2 ~]$ sudo sss_cache -E
> > > [martin@desk2 ~]$ sss_ssh_authorizedkeys martin
> > > Error looking up public keys
> > > 
> > > [have a coffee... really]
> > > 
> > > [martin@desk2 ~]$ sss_ssh_authorizedkeys martin
> > > ssh-rsa AAA...
> > > ssh-rsa AAA...
> > > ssh-ed25519 AAA...
> > > ssh-rsa AAA...
> > > ssh-rsa AAA...
> > 
> > If I understand it correctly you get the same result as on CentOS,
> > including the unexpected key derived from the certificate, after waiting
> > for some time? Can you send the sssd_ssh.log with the sequence from
> > above (if you prefer directly to me) so that I can check why it failed
> > in the first attempt and later succeeds.
> > 
> > bye,
> > Sumit
> > 
> 
> Hi,
> 
> yes, now the results are the same, including the originally unexpected key
> from certificate, and actual SSH pubkey auth finally works.
> 
> I would send you sssd_ssh.log, but it's empty - I have turned off
> debug_level sooner, sorry. :(
> 
> Isn't it the case that sss_cache -E takes few seconds to actually expire the
> cache entries?

sss_cache -E itself should be fast, but the next requests like
sss_ssh_authorizedkeys would need a bit longer because SSSD must now
read fresh data from the server. Nevertheless it should take some
seconds, maybe 10-20 with lots of group-memberships, but note as much as
a coffee break.

bye,
Sumit

> 
> Thank you.
> Martin
> 
> > > 
> > > 
> > > RH bug for selinux-policy:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1348447
> > > 
> > > Thank you!
> > > Martin
> > > 
> > > 
> > > On 6/21/2016 9:43 AM, Sumit Bose wrote:
> > > > On Mon, Jun 20, 2016 at 10:46:13PM +0200, Martin Štefany wrote:
> > > > > Hello all,
> > > > > 
> > > > > I've ran into strange issue with IPA/SSSD/SSH/SELinux which started 
> > > > > when I
> > > > > figured out that I cannot ssh with pubkey auth to Fedora 23 
> > > > > (ipa-client) systems
> > > > > while I can to CentOS 7.2 (ipa-client and ipa-server) systems within 
> > > > > same IPA
> > > > > domain. I will appreciate any help whatsoever.
> > > > > IPA servers (and most of the clients) are IPA 4.2.0 on CentOS 7.2 
> > > > > with latest
> > > > > updates, affected clients are IPA clients 4.2.4 on Fedora 23 with 
> > > > > latest
> > > > > updates.
> > > > > 
> > > > > I started by looking to the journal:
> > > > > jún 20 13:02:50 desk2.stefany.eu sshd[25162]: Connection
> > > > > from 144.xxx.xxx.xxx port 22543 on 172.17.100.191 port 22
> > > > > ...
> > > > > jún 20 13:02:56 desk2.stefany.eu audit[23328]: AVC avc:  denied  { 
> > > > > name_connect
> > > > > } for  pid=23328 comm="sssd_ssh" dest=80 
> > > > > scontext=system_u:system_r:sssd_t:s0
> > > > > tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket 
> > > > > permissive=0
> > > > > jún 20 13:02:56 desk2.stefany.eu audit[23328]: SYSCALL arch=c03e 
> > > > > syscall=42
> > > > > success=no exit=-13 a0=15 a1=7fff145c35b0 a2=10 a3=5614dbbe2a50 
> > > > > items=0
> > > > > ppid=23316 pid=23328 auid=4294967295 uid=0 gid=0 euid=0 suid=0 
> > > > > fsuid=0 egid=0
> > > > > sgid=0
> > > > 
> > > > Does the user by chance have a certificate added to his entry including
> > > &

Re: [Freeipa-users] Kinit with 2-Factor not working

[Sumit Bose]

On Wed, Jun 22, 2016 at 11:54:10AM -0400, Geordie Grindle wrote:
> 
> Hello,
> 
> On our current IPA realm where we have not used 2-factor, we’ve been able to 
> kinit to our FreeIPA realm from our laptops.  All a Mac user needed to do, 
> for example was to configure a ‘krb5.conf’ file and then ‘kinit 
> us...@our.ipa.realm.com '. This would allow 
> us to work on our infrastructure without having to re-authenticate for the 
> lifetime of our ticket-granting-ticket, usually the length of a work day.
> 
> We are building a new realm using 'ipa-server-4.2.0-15’ and will be requiring 
> 2-factor for authentication. So far it works well, meaning we can ssh to a 
> jump host enrolled in our realm and from there move to other hosts in the 
> realm without having to re-authenticate.
> 
> However, we can no longer ‘kinit’. I’ve dug around in the webs and have 
> concluded that either this is a known issue that is not yet fixed, or perhaps 
> someone has fixed it but not yet shared how they got this to work.

This is expected behaviour. See
http://www.freeipa.org/page/V4/OTP for details especially
http://www.freeipa.org/page/V4/OTP#kinit_Method.

Unfortunately in general you do not have a second ccache which can be
used to get the needed armor ticket for FAST. 

There is ongoing work on SPAKE
http://k5wiki.kerberos.org/wiki/Projects/SPAKE_preauth_prereqs and
also anonymous pkinit on the IPA side to lift the requirement but
currently FAST and a second ccache are needed for OTP.

HTH

bye,
Sumit

> 
> How is this impacting anyone else? Does anyone have any helpful information 
> they can share?
> 
> thanks,
> Geordie Grindle
> 
> 

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

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

Re: [Freeipa-users] freeIPA 4.2: Smart Card Issues

[Sumit Bose]

On Tue, Jun 28, 2016 at 04:41:39PM -0500, Michael Rainey (Contractor) wrote:
> Greetings,
> 
> Back in March I contacted the mailing list in regard to a problem I was
> having with smartcards and screen locking.  At that time I was provided a
> patch to implement to lock the screen when the smartcard was removed and it
> worked well.  Today it looks like the patch may have made its way to the
> repo and I am starting to see some issues occuring on my test machines.
> When the smartcard is inserted into the reader a message flashes on the
> screen "That didn't work.  Please try again."  Also, it doesn't seem to
> prompt for a pin for the smartcard.  It just shows the password field.
> Unfortunately, the logs didn't reveal much, I may need to tweak the debug
> level if more information is needed.

yes, it would be good if you can add debug_level=10 to the [pam] section
of sssd.conf and send the sssd_pam.log file after testing.

> 
> I grabbed the files from
> https://koji.fedoraproject.org/koji/taskinfo?taskID=13412048
> 
> I had to modify the smartcard-auth file to the following:
> 
> authrequired  pam_env.so
> authsufficientpam_sss.so allow_missing_name
> #auth[success=done ignore=ignore default=die] pam_pkcs11.so nodebug
> wait_for_card
> authrequired  pam_deny.so
> 
> account required  pam_unix.so
> account sufficientpam_localuser.so
> account sufficientpam_succeed_if.so uid < 1000 quiet
> account [default=bad success=ok user_unknown=ignore] pam_sss.so
> account required  pam_permit.so
> 
> #passwordrequired  pam_pkcs11.so
> 
> session optional  pam_keyinit.so revoke
> session required  pam_limits.so
> -session optional  pam_systemd.so
> session [success=1 default=ignore] pam_succeed_if.so service in crond
> quiet use_uid
> session required  pam_unix.so
> session optional  pam_sss.so
> 
> The dconf file /etc/dconf/db/distro.d/10-authconfig
> 
> [org/gnome/login-screen]
> enable-fingerprint-authentication=false
> 
> and /etc/dconf/db/distro.d/locks/10-authconfig-locks
> 
> /org/gnome/login-screen/enable-fingerprint-authentication

The configuration looks ok, I'll try to reproduce the issue locally as
well.

bye,
Sumit

> 
> I'm currently running the following:
> 
>  * Scientific Linux 7.2 64bit
>  * 4.2.0-15.sl7_2.17
>  * GDM 3.14.2
>  * GNOME Shell 3.14.4
> 
> Hopefully, I have given you enough information to work the problem. Have
> there been changes to the way freeIPA is configured for smartcard use?
> 
> Sincerely,
> -- 
> *Michael Rainey*
> 

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

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

Re: [Freeipa-users] FreeIPAv3 and SSSD // Disable automatic Kerberos authentication

[Sumit Bose]

On Wed, Jun 29, 2016 at 09:04:47AM +, tstorai@orange.com wrote:
> Hello,
> 
> We are using FreeIPAv3 with SSSD with Hortonworks Cluster :
> 
> -  ipa-admintools-3.0.0-47
> 
> -  ipa-client-3.0.0-47
> 
> -  sssd-ipa-1.11.6-30
> 
> 
> According with the following documentation, our users are automatically 
> authenticated to Kerberos at every login :
> https://www.freeipa.org/page/Kerberos
> "When SSSD project is used, the ticket is get for a user automatically as he 
> authenticates to client machine."
> 
> It's working pretty well but some of our users are using nominative accounts 
> for ssh connection then access to Hadoop with an applicative keytab...
> We are agreed than we have to perform a kinit at every connection but when 
> theses users work on several sessions they lose the applicative account 
> ticket :(

If you use credential cache collections (type DIR: or KEYTAB:) SSSD
would only update the individual cache matching the user principal
stored in IPA. The caches for other principals would persist. But if the
principal in the applicative keytab is from the same Kerberos realm you
still might need to use the 'kswitch' command to set the primary
principal. But it should be sufficient to call it only once because the
information is stored in the collection and not overwritten by SSSD.

If this does not work the affected users can add something like:

export KRB5CCNAME=$HOME/my_cc_cache

to their .bashrc (or related config file of other shells). Then at least
in the shell all commands, like e.g. ssh, would use my_cc_cache with the
credential from the kinit with the keytab.

HTH

bye,
Sumit


> 
> To resume :
> 1
> 
> User1 connect to the system with nominative account
> 
> Nominative Kerberos Ticket
> 
> 2
> 
> User1 use the applicative keytab to access to Hadoop
> 
> Applicative Kerberos Ticket
> 
> 3
> 
> User1 open a new session to the system with nominvative account
> 
> Nominative Kerberos Ticket --> Applicative Kerberos Ticket is lose
> 
> 
> Impact :
> --> Failed developpement
> --> Force the user to re-execute a kinit
> 
> We would know if it is possible to disable the automatic authentication in 
> provide with SSSD?
> 
> Thanks.
> 
> Regards,
> 
> Thibault
> 
> 
> _
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
> 

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

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

Re: [Freeipa-users] How to deactivate automatic kinit at ssh login ?

[Sumit Bose]

On Thu, Jun 30, 2016 at 08:54:16AM +0200, bahan w wrote:
> Hello !
> 
> I'm using freeipa 3.0.0-47.
> 
> I send you this mail concerning the automatic kinit at ssh login ? I wanted
> to know if it was possible to deactivate it on a specific server ?
> 
> The reason is that I have some of my users who often use another ticket
> that their own and this feature can be annoying for them.

Please have a look at my response to ' [Freeipa-users] FreeIPAv3 and
SSSD // Disable automatic Kerberos authentication'
(https://www.redhat.com/archives/freeipa-users/2016-June/msg00480.html)

HTH

bye,
Sumit

> 
> BR.
> 
> Bahan

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

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

Re: [Freeipa-users] k5login not working?

[Sumit Bose]

On Wed, Jul 06, 2016 at 03:30:56PM -0400, Jeffery Harrell wrote:
> I must be missing something really obvious.
> 
> Our IPA server is set up in the usual way on CentOS 7.2, just a “yum
> install ipa-server” and then an “ipa-server-install.” DNS is set up
> correctly and is working.
> 
> I’ve got a handful of CentOS 7.2 servers configured as IPA clients — “yum
> install ipa-client”, “ipa-client-install.” Auto-detection of the realm,
> domain and server were normal.
> 
> But k5login is not working as expected. If I have this .k5login file in the
> admin user’s home directory on server A:
> 
> alice@charlietango.com...@charlietango.com
> 
> I would expect to be able to do this:
> 
> kinit al...@charlietango.com
> ssh -K admin@serverA
> 
> from anywhere in the Kerberos realm. Instead my credentials get rejected
> and I’m asked for the admin user’s password.
> 
> It feels like sshd on the server isn’t even looking at k5login. (I also
> tried k5users; same result.)
> 
> The permissions on .k5login are correct. I tried it with SELinux off as
> well just in case that was it.
> 
> What blindingly obvious thing have I overlooked?

I guess you have an issue similar to
https://bugzilla.redhat.com/show_bug.cgi?id=1297462 . The localauth
plugin provided by SSSD has too stricts default settings. One is the
'enable_only = sssd' option in the config snippet. The other is that it
acts authoritative for SSSD users. A fix for both was just pushed
upstream today.

If you currently do not need the localauth plugin you can disable it by
creating an empty /var/lib/sss/pubconf/krb5.include.d/localauth_plugin
file and make it unmodifiable with 

chattr +i /var/lib/sss/pubconf/krb5.include.d/localauth_plugin

This should allow the default methods including k5login again. Please
note that you might need to add the old RULE based mapping as described
in
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/trust-ssh.html
or add .k5login files for every user to make GSSAPI authentication work
smoothly.

As an alternative we hope to release the next SSSD version including the
patches anytime soon and later on there might be build for 7.2
available.

HTH

bye,
Sumit

> 
> Thanks.

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

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

Re: [Freeipa-users] k5login not working?

[Sumit Bose]

On Wed, Jul 06, 2016 at 04:59:36PM -0400, Jeffery Harrell wrote:
> Oh wow, I see. I did some playing around with
> /var/lib/sss/pubconf/krb5.include.d/localauth_plugin in search of a
> minimum-change scenario and found that this:
> 
> [plugins]
>  localauth = {
>   module = sssd:/usr/lib64/sssd/modules/sssd_krb5_localauth_plugin.so
> #  enable_only = sssd
>  }
> 
> seems to get me where I need to be. Adding that one character seems to be
> enough to make .k5login work as expected.
> 
> Specifically:
> 
> Take a brand new IPA client, created with “ipa-client-install” and
> accepting the defaults.
> 
> Edit /var/lib/sss/pubconf/krb5.include.d/localauth_plugin to comment out
> the enable_only line as above.
> 
> cat <<'EOF' > /root/.k5loginyourusern...@yourdomain.com
> EOF
> 
> From another computer anywhere in the domain:
> 
> kinit yourusern...@yourdomain.com
> 
> Then:
> 
> ssh -K root@wherever
> 
> This works for me. I’ve got all my servers under Salt config management
> anyway, so it’s not *that* big a deal to add that one byte to each of them.

ok, make sense. As long as the target users are local (from /etc/passwd)
removing 'enable_only = sssd'. For IPA users sssd_krb5_localauth_plugin
would still act authoritative, i.e. you have to remove/comment-out it as
well if you want to use k5login for IPA user to IPA user.

Please note that SSSD will rewrite the file on restart, so you still
might want to use chattr +i to keep your changes.

> 
> Thank you very, very much for the help.

You're welcome.

bye,
Sumit

> 
> 
> 
> 
> On July 6, 2016 at 1:00:53 PM, Sumit Bose (sb...@redhat.com) wrote:
> 
> On Wed, Jul 06, 2016 at 03:30:56PM -0400, Jeffery Harrell wrote:
> > I must be missing something really obvious.
> >
> > Our IPA server is set up in the usual way on CentOS 7.2, just a “yum
> > install ipa-server” and then an “ipa-server-install.” DNS is set up
> > correctly and is working.
> >
> > I’ve got a handful of CentOS 7.2 servers configured as IPA clients — “yum
> > install ipa-client”, “ipa-client-install.” Auto-detection of the realm,
> > domain and server were normal.
> >
> > But k5login is not working as expected. If I have this .k5login file in
> the
> > admin user’s home directory on server A:
> >
> > alice@charlietango.com...@charlietango.com
> >
> > I would expect to be able to do this:
> >
> > kinit al...@charlietango.com
> > ssh -K admin@serverA
> >
> > from anywhere in the Kerberos realm. Instead my credentials get rejected
> > and I’m asked for the admin user’s password.
> >
> > It feels like sshd on the server isn’t even looking at k5login. (I also
> > tried k5users; same result.)
> >
> > The permissions on .k5login are correct. I tried it with SELinux off as
> > well just in case that was it.
> >
> > What blindingly obvious thing have I overlooked?
> 
> I guess you have an issue similar to
> https://bugzilla.redhat.com/show_bug.cgi?id=1297462 . The localauth
> plugin provided by SSSD has too stricts default settings. One is the
> 'enable_only = sssd' option in the config snippet. The other is that it
> acts authoritative for SSSD users. A fix for both was just pushed
> upstream today.
> 
> If you currently do not need the localauth plugin you can disable it by
> creating an empty /var/lib/sss/pubconf/krb5.include.d/localauth_plugin
> file and make it unmodifiable with
> 
> chattr +i /var/lib/sss/pubconf/krb5.include.d/localauth_plugin
> 
> This should allow the default methods including k5login again. Please
> note that you might need to add the old RULE based mapping as described
> in
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/trust-ssh.html
> or add .k5login files for every user to make GSSAPI authentication work
> smoothly.
> 
> As an alternative we hope to release the next SSSD version including the
> patches anytime soon and later on there might be build for 7.2
> available.
> 
> HTH
> 
> bye,
> Sumit
> 
> >
> > Thanks.
> 
> > --
> > 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

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

Re: [Freeipa-users] Unable to ssh after establishing trust

[Sumit Bose]

On Mon, Jul 11, 2016 at 03:46:57AM +, pgb205 wrote:
> I have successfully established trust and am able to obtain ticket granting 
> ticketkinit user@AD_DOMAIN.COMI can also do kinit admin@IPA_DOMAIN.COMssh 
> admin@IPA_DOMAIN.COM also works
> however, ssh user@AD_DOMAIN.COM or user@ad_domain.com fails
> I have checked that there are no hbac rules other then the default allow_all 
> rule
> in sssd_ssh.log see
> permission denied (6) error in sssd_ipa.domain.log file I see
> pam_handler_callback 6 permission_denied
> in sssd_nss.log Unable to get information from Data ProviderError: 3 Account 
> info lookup failedWill try to return what we have in cache
> in /var/log/secure received for user user@AD_DOMAIN.COM: 6 (Permission 
> denied) 
> 
> I can provided full logs if necessary to diagnose the above problem.

Yes, full SSSD logs with debug_level=10 would be best.

> --Additionally, I would like to be able to login as user not 
> user@AD_DOMAIN.COM
> My understanding that only thing that I have to change to make this happen is 
> /etc/krb5.conffor line 
> [libdefaults] default_realm=AD_DOMAN.COM and then restarting ipa services.

No, please do not change the default_realm. This is not related to the
issues you are seeing.

bye,
Sumit

> However, when I do this I get failure to restart Samba service

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

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

Re: [Freeipa-users] HBAC and AD users

[Sumit Bose]

On Mon, Jul 11, 2016 at 04:55:37PM +1000, Lachlan Musicman wrote:
> On 11 July 2016 at 16:44, Alexander Bokovoy  wrote:
> 
> > On Mon, 11 Jul 2016, Lachlan Musicman wrote:
> >
> >> Hola,
> >>
> >> Centos 7, up to date.
> >>
> >> [root@linuxidm ~]# ipa --version
> >> VERSION: 4.2.0, API_VERSION: 2.156
> >>
> >> One way trust is successfully established, can login with
> >>
> >> ssh usern...@domain1.com@server1.domain2.com
> >>
> >> Am testing to get HBAC to work.
> >>
> >> I've noticed that with the Allow All rule in effect, the following set up
> >> is sufficient:
> >>
> >> add external group "ad_external"
> >> add internal group, "ad_internal", add ad_external as a group member of
> >> ad_internal
> >>
> >> AD users can now successfully login to any server.
> >>
> >> When I tried to set up an HBAC, I couldn't get that set up to work, I
> >> needed to complete the extra step of adding AD users explicitly to the
> >> "external member" group of the external group.

yes, this is expected you either have to add AD users or groups to the
external groups.

> >>
> >> I also note that this seems to be explicitly user based, not group based?
> >> IE, I can add lach...@domain1.com to the external members of ad_external
> >> and that works, but adding the group server_adm...@domain1.com (as seen
> >> in
> >> `id lach...@domain1.com`) doesn't allow all members access.

Since it looks you are using FreeIPA 4.2 you might hit
https://fedorahosted.org/freeipa/ticket/5573 . But SSSD logs, especially
the part where the HBAC rules are evaluated would help to understand the
issue better.

> >>
> >> Does that sound correct?
> >>
> > No, it does not.
> > HBAC evaluation and external group merging/resolution is done by SSSD.
> > Use https://fedorahosted.org/sssd/wiki/Troubleshooting to produce logs
> > that can help understanding what happens there.
> >
> > What SSSD version do you have on both IPA client and IPA server?
> 
> 
> 
> 1.13.0 on both client and server.
> 
> To be honest, we have ratcheted up the logs and it doesn't help that much.
> We just got lots of "unsupported PAM command [249]"

This is unrelated, I assume this happens when trying to store the hashed
password to the cache. This message is remove in newer releases.

bye,
Sumit

> 
> Cheers
> L.

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

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

Re: [Freeipa-users] HBAC and AD users

[Sumit Bose]

On Tue, Jul 12, 2016 at 09:08:01AM +1000, Lachlan Musicman wrote:
> Alex, Sumit,
> 
> Which log levels would you recommend for sssd to help debug this issue?
> 
> We've been using 7, but I just realised that it's not an increasing scale
> but bitmasked...

It is both 0-9 is increasing scale while values above 16 are treated as
bitmask. Please just use 9 to get all messages.

bye,
Sumit

> 
> cheers
> L.
> 
> --
> The most dangerous phrase in the language is, "We've always done it this
> way."
> 
> - Grace Hopper
> 
> On 11 July 2016 at 17:15, Sumit Bose  wrote:
> 
> > On Mon, Jul 11, 2016 at 04:55:37PM +1000, Lachlan Musicman wrote:
> > > On 11 July 2016 at 16:44, Alexander Bokovoy  wrote:
> > >
> > > > On Mon, 11 Jul 2016, Lachlan Musicman wrote:
> > > >
> > > >> Hola,
> > > >>
> > > >> Centos 7, up to date.
> > > >>
> > > >> [root@linuxidm ~]# ipa --version
> > > >> VERSION: 4.2.0, API_VERSION: 2.156
> > > >>
> > > >> One way trust is successfully established, can login with
> > > >>
> > > >> ssh usern...@domain1.com@server1.domain2.com
> > > >>
> > > >> Am testing to get HBAC to work.
> > > >>
> > > >> I've noticed that with the Allow All rule in effect, the following
> > set up
> > > >> is sufficient:
> > > >>
> > > >> add external group "ad_external"
> > > >> add internal group, "ad_internal", add ad_external as a group member
> > of
> > > >> ad_internal
> > > >>
> > > >> AD users can now successfully login to any server.
> > > >>
> > > >> When I tried to set up an HBAC, I couldn't get that set up to work, I
> > > >> needed to complete the extra step of adding AD users explicitly to the
> > > >> "external member" group of the external group.
> >
> > yes, this is expected you either have to add AD users or groups to the
> > external groups.
> >
> > > >>
> > > >> I also note that this seems to be explicitly user based, not group
> > based?
> > > >> IE, I can add lach...@domain1.com to the external members of
> > ad_external
> > > >> and that works, but adding the group server_adm...@domain1.com (as
> > seen
> > > >> in
> > > >> `id lach...@domain1.com`) doesn't allow all members access.
> >
> > Since it looks you are using FreeIPA 4.2 you might hit
> > https://fedorahosted.org/freeipa/ticket/5573 . But SSSD logs, especially
> > the part where the HBAC rules are evaluated would help to understand the
> > issue better.
> >
> > > >>
> > > >> Does that sound correct?
> > > >>
> > > > No, it does not.
> > > > HBAC evaluation and external group merging/resolution is done by SSSD.
> > > > Use https://fedorahosted.org/sssd/wiki/Troubleshooting to produce logs
> > > > that can help understanding what happens there.
> > > >
> > > > What SSSD version do you have on both IPA client and IPA server?
> > >
> > >
> > >
> > > 1.13.0 on both client and server.
> > >
> > > To be honest, we have ratcheted up the logs and it doesn't help that
> > much.
> > > We just got lots of "unsupported PAM command [249]"
> >
> > This is unrelated, I assume this happens when trying to store the hashed
> > password to the cache. This message is remove in newer releases.
> >
> > bye,
> > Sumit
> >
> > >
> > > Cheers
> > > L.
> >
> > > --
> > > 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
> >
> >

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

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

Re: [Freeipa-users] IPA HBAC access using SSSD for user in trusted AD domain (RHEL 6.8)

[Sumit Bose]

On Wed, Jul 13, 2016 at 08:37:44AM +0200, Jakub Hrozek wrote:
> On Wed, Jul 13, 2016 at 09:10:07AM +0300, Alexander Bokovoy wrote:
> > On Tue, 12 Jul 2016, Sullivan, Daniel [AAA] wrote:
> > > Justin,
> > > 
> > > I really appreciate you taking the time to respond to me.  This problem
> > > is driving me crazy and I will certainly take any help I can get. My
> > > suspicion is that the external user group in the policy below was
> > > causing the log entry you specified, removing it from the policy does
> > > not remediate the problem, even after flushing the client cache.
> > > 
> > > The way I have this setup is as follows:
> > > 
> > > 1) I created a POSIX group in IPA named
> > > 'cri-cri_server_administrators_ipa' and allowed IPA to assign the GID.
> > > 2) I created an external group in IPA named
> > > 'cri-cri_server_administrators_external’ and added the AD group in the
> > > trusted domain as an external member to this group
> > > (cri-cri_server_administrat...@bsdad.uchicago.edu).
> > > 3) I added the group cri-cri_server_administrators_external' as a
> > > member of 'cri-cri_server_administrators_ipa’
> > > 
> > > The HBAC rule is configured as (removing the external group does not
> > > seem to make a difference).
> > > 
> > > [root@cri-ksysipadcp2 a.cri.dsullivan]# ipa hbacrule-show 
> > > 'cri-cri_server_administrators_allow_all'
> > >  Rule name: cri-cri_server_administrators_allow_all
> > >  Host category: all
> > >  Service category: all
> > >  Description: Allow anyone in 
> > > cri-cri_server_administrat...@bsdad.uchicago.edu
> > >  to login to any machine
> > >  Enabled: TRUE
> > >  User Groups: cri-cri_server_administrators_external, 
> > > cri-cri_server_administrators_ipa
> > > [root@cri-ksysipadcp2 a.cri.dsullivan]#
> > > 
> > > For example, the problem still persists when the policy is configured in 
> > > this manner:
> > > 
> > > [root@cri-ksysipadcp2 a.cri.dsullivan]# ipa hbacrule-show 
> > > 'cri-cri_server_administrators_allow_all'
> > >  Rule name: cri-cri_server_administrators_allow_all
> > >  Host category: all
> > >  Service category: all
> > >  Description: Allow anyone in 
> > > cri-cri_server_administrat...@bsdad.uchicago.edu to login to any machine
> > >  Enabled: TRUE
> > >  User Groups: cri-cri_server_administrators_ipa
> > > 
> > > And my login validates against the host in question as follows:
> > > 
> > > As I said I have this working consistently (i.e. can flush the cash) on
> > > another host with the same exact version of IPA and SSSD.  Here is a
> > > validation of hbactest (works with either of the two policy
> > > configurations above).
> > I think you problems are related to this snippet of your domain log
> > where SSSD on IPA client was unable to add membership of your user to
> > any of these groups:
> > 

...

> > 
> > as result, the user is viewed by SSSD on this IPA client as not
> > belonging to the cri-cri_server_administrat...@bsdad.uchicago.edu group
> > and thus, HBAC rule validation on this client fails.
> 
> First, we have some debug messages in this part of sssd that can really
> use some improvement. That is, some debug messages are expected to
> report failures and we recover from them later.
> 
> But in general Alexander is right. Does 'id
> a.cri.dsulli...@bsdad.uchicago.edu' report the user as a member of the
> group that should be allowing access?
> 
> If not, I would suggest to run:
> 1) sss_cache -E on both server and client (don't remove the cache,
> please)
> 2) truncate the logs on server and client
> 3) run id a.cri.dsulli...@bsdad.uchicago.edu on the client
> then send us the logs from that single id run..

If some of the IPA group memberships are missing you might hit
https://bugzilla.redhat.com/show_bug.cgi?id=1304333 which is not fixed
in the IPA version you use (ipa-4.2.0-15.el7_2.6.1).

Mabye upgrading the server helps?

bye,
Sumit

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

Re: [Freeipa-users] Unable to ssh after establishing trust

[Sumit Bose]

On Tue, Jul 12, 2016 at 06:40:22PM +, pgb205 wrote:
> +freeipa-users list
> 
>   From: pgb205 
>  To: Sumit Bose  
>  Sent: Tuesday, July 12, 2016 2:12 PM
>  Subject: Re: [Freeipa-users] Unable to ssh after establishing trust
>
> Sumit, thanks for replying
> So the first issue is my fault, probably from when I was sanitizing logs. 
> our active directory domain is ad_domain.local, but users would expect to 
> login as userid@ad_domain.com or just userid.for ipa the kerberos realm is 
> IPA_DOMAIN.INTERNAL and domain is ipa_domain.internal.
> ewr-fipa_server used to be old trial server so I am not sure why it's still 
> in the dns lookup results. I'll check this part further.
> Lastly. only the connection to one of the domain controllers on AD side is 
> open. As discussed previously with Alexandr BokovoyI forced, in 
> /etc/krb5.conf, a connection to this single, accessible domain controller. 
> Are there any other files where I would needto lock down the connections 
> between ipa->ad so that all traffic goes to specific active directory domain 
> controller?
> thanks again for replying so quickly.

Currently it is not possible to specify individual AD DC SSSD on the IPA
server should talk to. We have ticket
https://fedorahosted.org/sssd/ticket/2599 to make this possible in some
later versions of SSSD. 

Currently SSSD uses a DNS SRV lookup like _ldap._tcp.ad_domain.local to
get a list of AD DC, then picks one to get the next nearest site for the
IPA domain and finally tries to lookup a DC from the matching site (if
any).

According to your logs SSSD was able to find 18 DCs with the SRV lookup.
A call like

dig SRV _ldap._tcp.ad_domain.local

on the IPA server should return the same list of 18 DCs.

As a work-around, or better a hack, you might want to try to set the IP
address of all the 18 DC returned to the IP address of the only
accessible DC in /etc/hosts. This way SSSD should have no chance to
connect to a different DC.

bye,
Sumit

> 
>   From: Sumit Bose 
>  To: pgb205  
> Cc: Sumit Bose 
>  Sent: Tuesday, July 12, 2016 5:37 AM
>  Subject: Re: [Freeipa-users] Unable to ssh after establishing trust
>   
> On Mon, Jul 11, 2016 at 09:14:03PM +, pgb205 wrote:
> > Sumit, 
> > sssd log files attached with debug=10 in all sections.I have attempted 
> > several logins for comparison as well as kinit commands
> 
> I came across two issues in the logs.
> 
> First it looks like you use 'user@AD_DOMAIN.LOCAL' at the login prompt
> but there seem to be an alternative domain suffix 'AD_DOMAIN.COM' on the
> AD side and user principal attributes 'user@AD_DOMAIN.COM'. Currently
> FreeIPA cannot resolve those principals correctly. It was planned for
> IPA 4.4.0 and SSSD 1.14.0 but because of an issue found in 4.4.0 it will
> be available (hopefully) with IPA 4.4.1 and SSSD 1.14.1. In the meantime
> please try to work-around suggested at the end of
> http://osdir.com/ml/freeipa-users/2016-01/msg00304.html . When trying to
> authenticate with user@AD_DOMAIN.COM SSSD looks for a server called
> ewr-fipa_server.ad_domain.com but cannot find it an return the error code
> for "Cannot contact any KDC for requested realm".
> 
> Second there are some issues access AD DCs via LDAP. SSSD tries to
> connect to mm-sfdc01.ad_domain.local and mm-tokyo-02.ad_domain.local but
> both fails. It is not clear from the logs if already the DNS lookup for
> those fails or if the connection itself runs into a timeout. In the
> former case you should make sure that the names can be resolved in the
> IPA server in the latter you can try to increase ldap_network_timeout
> (see man sssd-ldap for details). Since SSSD cannot connect to the DCs it
> switches the AD domains to offline. The authentication request is
> handled offline as well but since there are no cached credentials you
> get the permission denied error.
> 
> HTH
> 
> bye,
> Sumit
> 
> > 
> >      From: Sumit Bose 
> >  To: pgb205  
> > Cc: "Freeipa-users@redhat.com" 
> >  Sent: Monday, July 11, 2016 3:06 AM
> >  Subject: Re: [Freeipa-users] Unable to ssh after establishing trust
> >    
> > On Mon, Jul 11, 2016 at 03:46:57AM +, pgb205 wrote:
> > > I have successfully established trust and am able to obtain ticket 
> > > granting ticketkinit user@AD_DOMAIN.COMI can also do kinit 
> > > admin@IPA_DOMAIN.COMssh admin@IPA_DOMAIN.COM also works
> > > however, ssh user@AD_DOMAIN.COM or user@ad_domain.com fails
> > > I have checked that there are no hbac rules other then the default 
> > > allow_all rule
> > > in sssd_ssh.log see
> > > permission denied (6) error in sssd_ipa.domain.log

Re: [Freeipa-users] HBAC and AD users

[Sumit Bose]

On Thu, Jul 14, 2016 at 11:47:41AM +1000, Lachlan Musicman wrote:
> Ok, I have some logs of sssd 1.13.0 not working. Same values as before:
> 
> FreeIPA server: Centos 7, ipa 4.2, API_VERSION 2.156
> 
> Installed Packages
> Name: ipa-server
> Arch: x86_64
> Version : 4.2.0
> Release : 15.0.1.el7.centos.17
> Size: 5.0 M
> Repo: installed
> >From repo   : updates
> Summary : The IPA authentication server
> 
> 
> Successfully joined in one way trust to AD.
> 
> Successfully have added hosts (Centos 7, sssd 1.13.0).
> 
> 
> [root@vmpr-linuxidm ~]# ipa hbacrule-find
> 
> 5 HBAC rules matched
> 
> 
>   Rule name: allow_all
>   User category: all
>   Host category: all
>   Service category: all
>   Description: Allow all users to access any host from any host
>   Enabled: FALSE
> 
> ...
> 
>   Rule name: ssh to galaxy
>   Service category: all
>   Description: Allows ssh to galaxy server
>   Enabled: TRUE
>   User Groups: ad_users
>   Hosts: papr-res-galaxy.unix.petermac.org.au
> 
> 
> 
> 
> With allow_all HBAC rule enabled, can login every time with
> 
> ssh user@ad_domain@unix_host
> 
> If I implement a HBAC rule "ssh to galaxy" as per above, with:
> 
> ad_users is a POSIX group with a GID. It has one member, the group
> 
> ad_external an external group with a single, external, member
> 
> pmc-res-ipaus...@petermac.org.au
> 
> which is an AD group containing all the users that should have access to
> the host.
> 
> 
> With allow_all disabled and "ssh to galaxy" enabled, some users can login
> and some can't. There is no discernable pattern that might explain why some
> are discriminated against.
> 
> Here is the test from the server:
> 
> [root@vmpr-linuxidm ~]# ipa hbactest --user=sandsjor...@petermac.org.au
> --host=papr-res-galaxy.unix.petermac.org.au --service=sshd
> 
> Access granted: True
> 
>   Matched rules: ssh to galaxy
>   Not matched rules: Computing Cluster
>   Not matched rules: FACS Computing
> 
> I've installed ipa-admintools on the host in question and got the same
> result.
> 
> To be on the safe side/tick all boxes, I have cleared the cache on the host
> in question:
> 
> systemctl stop sssd
> sss_cache -E
> systemctl start sssd
> 
> and confirmed success with a status check.
> 
> When the user tries to login, it fails.
> 
> Log is here:
> 
> http://dpaste.com/0VAFNPH
> 
> 
> The top is where the negotiating starts to the best of my knowledge.
> 
> The attempts fails, with no information that is useful to me:
> 
> 230 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
> [hbac_get_category] (0x0200): Category is set to 'all'.
> 231 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
> [hbac_thost_attrs_to_rule] (0x1000): Processing target hosts for rule [ssh
> to galaxy]
> 232 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
> [hbac_shost_attrs_to_rule] (0x0400): Processing source hosts for rule [ssh
> to galaxy]
> 233 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
> [hbac_eval_user_element] (0x1000): [3] groups for [
> sandsjor...@petermac.org.au]

According to the HBAC evaluation the user is a member of 3 groups. Is
this the expected number?

Can you check if 'id sandsjor...@petermac.org.au' returns the expected
list of groups on the client and the IPA server? (The client does not
talk to AD directly only to the IPA server, so if something is already
missing on the server it cannot be seen on the client as well).

Can you send me the SSSD cache file from the client
/var/lib/sss/db/cache_unix.petermac.org.au.ldb after the login attempt?
Since it might contain password hashes you might want to remove
lines with 'cachedPassword' before

bye,
Sumit


> 234 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
> [ipa_hbac_evaluate_rules] (0x0080): Access denied by HBAC rules
> 235 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
> [be_pam_handler_callback] (0x0100): Backend returned: (0, 6, )
> [Success (Permission denied)]
> 236 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
> [be_pam_handler_callback] (0x0100): Sending result [6][petermac.org.au]
> 237 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
> [be_pam_handler_callback] (0x0100): Sent result [6][petermac.org.au]
> 
> 
> Cheers
> L.
> 
> 
> --
> The most dangerous phrase in the language is, "We've always done it this
> way."
> 
> - Grace Hopper
> 
> On 12 July 2016 at

Re: [Freeipa-users] Ghost ipaSshPubKey in sss_ssh_authorizedkeys or 'Error looking up public keys'

[Sumit Bose]

On Sun, Jul 17, 2016 at 11:21:34PM +0200, Martin Štefany wrote:
> On So, 2016-07-16 at 15:37 +0200, Lukas Slebodnik wrote:
> > On (16/07/16 10:19), Martin Štefany wrote:
> > > 
> > > Hello Sumit,
> > > 
> > > seems that upgrade to F24 broke things again. This time no AVCs, empty 
> > > SSSD
> > > logs, but same problem: 'Error looking up public keys'.
> > > 
> > > selinux-policy-3.13.1-191.fc24.3.noarch
> > > selinux-policy-targeted-3.13.1-191.fc24.3.noarch
> > > sssd-1.13.4-3.fc24.x86_64
> > > 
> > Fedora 23 and fedora 24 has the same version of sssd
> > and almost the same version of openssh.
> > I have no idea what coudl broke it it there are not any AVCs.
> > 
> > > 
> > > Using debug_level 0x0250 ::
> > > 
> > For troubleshooting, it would be better to see all
> > debug messages. (debug_level = 0xfff0)
> 
> Hello Lukas,
> 
> thanks for replying on this, here are debug_level = 0xfff0 messages
> 

...

> (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [cert_to_ssh_key] (0x0020):
> CERT_VerifyCertificateNow failed [-8179].
> (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [decode_and_add_base64_data] (0x0040):
> cert_to_ssh_key failed.

-8179 translates to "Peer's certificate issuer is not recognized."
(http://www-archive.mozilla.org/projects/security/pki/nss/ref/ssl/sslerr.html).
This means the CA certificate which signed the certificate on the
Smartcard is missing in /etc/pki/nssdb which is used by default by SSSD.

Recent version of IPA put IPA CA certificates only in /etc/ipa/nssdb,
this might be the reason why you see this with F24.

To fix this please either add the needed CA certificates to
/etc/pki/nssdb with certutil or add 'ca_db = /etc/ipa/nssdb' to the
[ssh] section of sssd.conf if /etc/ipa/nssdb already has all needed CA
certificates to validate the Smartcard certificate. 

I'm working on a fix for SSSD to handle handle this change
automatically, but unfortunately it is not ready yet.

HTH

bye,
Sumit

> 
> > > 
> > > $ /usr/bin/sss_ssh_authorizedkeys martin
> > > Error looking up public keys
> > > 
> > And try to run strace with sss_ssh_authorizedkeys
> > 
> > LS
> 
> Martin

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

Re: [Freeipa-users] Ghost ipaSshPubKey in sss_ssh_authorizedkeys or 'Error looking up public keys'

[Sumit Bose]

On Mon, Jul 18, 2016 at 09:54:37AM -0400, Rob Crittenden wrote:
> Sumit Bose wrote:
> > On Sun, Jul 17, 2016 at 11:21:34PM +0200, Martin Štefany wrote:
> > > On So, 2016-07-16 at 15:37 +0200, Lukas Slebodnik wrote:
> > > > On (16/07/16 10:19), Martin Štefany wrote:
> > > > > 
> > > > > Hello Sumit,
> > > > > 
> > > > > seems that upgrade to F24 broke things again. This time no AVCs, 
> > > > > empty SSSD
> > > > > logs, but same problem: 'Error looking up public keys'.
> > > > > 
> > > > > selinux-policy-3.13.1-191.fc24.3.noarch
> > > > > selinux-policy-targeted-3.13.1-191.fc24.3.noarch
> > > > > sssd-1.13.4-3.fc24.x86_64
> > > > > 
> > > > Fedora 23 and fedora 24 has the same version of sssd
> > > > and almost the same version of openssh.
> > > > I have no idea what coudl broke it it there are not any AVCs.
> > > > 
> > > > > 
> > > > > Using debug_level 0x0250 ::
> > > > > 
> > > > For troubleshooting, it would be better to see all
> > > > debug messages. (debug_level = 0xfff0)
> > > 
> > > Hello Lukas,
> > > 
> > > thanks for replying on this, here are debug_level = 0xfff0 messages
> > > 
> > 
> > ...
> > 
> > > (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [cert_to_ssh_key] (0x0020):
> > > CERT_VerifyCertificateNow failed [-8179].
> > > (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [decode_and_add_base64_data] 
> > > (0x0040):
> > > cert_to_ssh_key failed.
> > 
> > -8179 translates to "Peer's certificate issuer is not recognized."
> > (http://www-archive.mozilla.org/projects/security/pki/nss/ref/ssl/sslerr.html).
> > This means the CA certificate which signed the certificate on the
> > Smartcard is missing in /etc/pki/nssdb which is used by default by SSSD.
> > 
> > Recent version of IPA put IPA CA certificates only in /etc/ipa/nssdb,
> > this might be the reason why you see this with F24.
> > 
> > To fix this please either add the needed CA certificates to
> > /etc/pki/nssdb with certutil or add 'ca_db = /etc/ipa/nssdb' to the
> > [ssh] section of sssd.conf if /etc/ipa/nssdb already has all needed CA
> > certificates to validate the Smartcard certificate.
> > 
> > I'm working on a fix for SSSD to handle handle this change
> > automatically, but unfortunately it is not ready yet.
> 
> The client installer should be adding the IPA CA to the system certificate
> store which should be picked up automagically by OpenSSL and NSS
> applications. I think I'd start there to see if that happened.

The responsibility for this was delegated to p11-kit in
11592dde1b232a70f318e01f5271b38890090648. Not sure if it was expected
that p11-kit-proxy will be added to /etc/pki/nssdb by default?

bye,
Sumit

> 
> rob
> 

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

Re: [Freeipa-users] Unable to ssh after establishing trust

[Sumit Bose]

On Mon, Jul 18, 2016 at 09:21:07PM +, pgb205 wrote:
> Sumit,
> 
> I have set the names of all the Domain Controllers to be resolvable to the IP
> of the one reachable Domain Controller in /etc/hosts
> 
> /etc/hosts:
> Reachable_IP_BOX   172.10.10.1
> DC1172.10.10.1
> DC2172.10.10.1
> ...
> ...

The IP address should come first, please see man hosts for details.

> 
> However, I still see the following
> Marking SRV lookup of service 'gc_addomain.local' as 'neutral'
> Marking server dc1.addomain.local' as 'name not resolved'

Have you tried to add the fully-qualified names (dc1.addomain.local) in
the right format (see above) to /etc/hosts?

> 
> 
> Additionally I have configured 
> [domain/ipa.internal]
>   with 
> subdomain_inherit = ldap_user_principal
> ldap_user_principal = nosuchattr
> 
> 
> As far as your earlier note about seeing ewr-fipa-x1 in logs. That used to be
> the old hostname of the IPA KDC.
> After much troubleshooting I believe I got this fixed by deleting  extra
> folders in
> /var/named/dyndb-ldap/ipa/master
> Right now the only two folders are ipa.internal and .in-addr.arpa.
> I think this is what helped with this issue. but can you please confirm if it
> sounds reasonable.

Not sure how you got the additional directories but if on only have a
single IPA DNS domain the two directories are sufficient.

bye,
Sumit

> 
> 
> Ssh is still failing, possibly due to the problem 1 above. Is there anything
> else I can do to force ipa to pay attention to the /etc/hosts ?
> Or is this some other issue?
> 
> thanks
> ━━━
> From: Sumit Bose 
> To: pgb205 
> Cc: Sumit Bose ; Freeipa-users 
> Sent: Wednesday, July 13, 2016 5:43 AM
> Subject: Re: [Freeipa-users] Unable to ssh after establishing trust
> 
> On Tue, Jul 12, 2016 at 06:40:22PM +, pgb205 wrote:
> > +freeipa-users list
> >
> >  From: pgb205 
> >  To: Sumit Bose 
> >  Sent: Tuesday, July 12, 2016 2:12 PM
> >  Subject: Re: [Freeipa-users] Unable to ssh after establishing trust
> >   
> > Sumit, thanks for replying
> > So the first issue is my fault, probably from when I was sanitizing logs. 
> > our active directory domain is ad_domain.local, but users would expect to
> login as userid@ad_domain.com or just userid.for ipa the kerberos realm is
> IPA_DOMAIN.INTERNAL and domain is ipa_domain.internal.
> > ewr-fipa_server used to be old trial server so I am not sure why it's still
> in the dns lookup results. I'll check this part further.
> > Lastly. only the connection to one of the domain controllers on AD side is
> open. As discussed previously with Alexandr BokovoyI forced, in 
> /etc/krb5.conf,
> a connection to this single, accessible domain controller. Are there any other
> files where I would needto lock down the connections between ipa->ad so that
> all traffic goes to specific active directory domain controller?
> > thanks again for replying so quickly.
> 
> Currently it is not possible to specify individual AD DC SSSD on the IPA
> server should talk to. We have ticket
> https://fedorahosted.org/sssd/ticket/2599 to make this possible in some
> later versions of SSSD.
> 
> Currently SSSD uses a DNS SRV lookup like _ldap._tcp.ad_domain.local to
> get a list of AD DC, then picks one to get the next nearest site for the
> IPA domain and finally tries to lookup a DC from the matching site (if
> any).
> 
> According to your logs SSSD was able to find 18 DCs with the SRV lookup.
> A call like
> 
> dig SRV _ldap._tcp.ad_domain.local
> 
> on the IPA server should return the same list of 18 DCs.
> 
> As a work-around, or better a hack, you might want to try to set the IP
> address of all the 18 DC returned to the IP address of the only
> accessible DC in /etc/hosts. This way SSSD should have no chance to
> connect to a different DC.
> 
> bye,
> 
> Sumit
> 
> >
> >  From: Sumit Bose 
> >  To: pgb205 
> > Cc: Sumit Bose 
> >  Sent: Tuesday, July 12, 2016 5:37 AM
> >  Subject: Re: [Freeipa-users] Unable to ssh after establishing trust
> > 
> > On Mon, Jul 11, 2016 at 09:14:03PM +, pgb205 wrote:
> > > Sumit, 
> > > sssd log files attached with debug=10 in all sections.I have attempted
> several logins for comparison as well as kinit commands
> >
> > I came across two issues in the logs.
> >
> > First it looks like you use 'user@AD_DOMAIN.LOCAL' at the login prompt
> > but there seem to be an alternative domain suffix &

Re: [Freeipa-users] nfsidmap oddity

[Sumit Bose]

On Fri, Aug 26, 2016 at 08:39:05AM -0400, William Muriithi wrote:
> Morning
> 
> I have been struggling with nfsidmap issue for a couple of days and
> wouldn't mind a fresh eyes.
> 
> Essentially, I have a FreeIPA that has a trust relationship with AD.
> The AD is on domain example-corp.example.com while FreeIPA manages
> eng.example.com.  The problem is, when I login using AD account, the
> nfsidmap seem to think I am on the FreeIPA account.  I have changed
> the idnapd.conf to use AD domain but that doesn't help.
> 
> vi /etc/idmapd.conf
> 
> Domain = example-corp.example.com

Which translation method do you use? SSSD provides an own method which
should be more flexible than the default ones, see iman sss_rpcidmapd
for details.

HTH

bye,
Sumit

> 
> 
> 
> [william@cacti ~]$ ssh 'william@example-corp'@platinum.eng.example.com
> 
> william@example-c...@platinum.eng.example.com's password:
> 
> Last login: Tue Aug 23 11:45:33 2016 from 192.168.20.28
> 
> [will...@example-corp.example.com@platinum ~]$ env | grep USER
> 
> USER=will...@example-corp.example.com
> 
> [will...@example-corp.example.com@platinum ~]$ su
> 
> Password:
> 
> [root@platinum william]# tail /var/log/messages
> 
> Aug 26 08:18:13 platinum nfsidmap[17780]: nss_getpwnam: name
> 'r...@eng.example.com' does not map into domain
> 'example-corp.example.com'
> 
> Aug 26 08:18:13 platinum nfsidmap[17784]: nss_getpwnam: name
> 'will...@eng.example.com' does not map into domain
> 'example-corp.example.com'
> 
> -- 
> 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

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

Re: [Freeipa-users] SSH login using putty from Windows to SSSD client in IPA AD trust

[Sumit Bose]

On Wed, Sep 07, 2016 at 10:27:17AM +0300, Alexander Bokovoy wrote:
> On Wed, 07 Sep 2016, Troels Hansen wrote:
> > Running RHEL 7.2, IPA 4.2 and SSSD 1.13, we have set up a IPA-AD trust
> > and trying to get Putty GSSAPI login to work.  In Putty GSSAPI have
> > been enabled, and GSSAPI is enabled in sshd.
> > 
> > Logging in using password from Windows to Linux works, and logging in
> > from Linux to Linux using kerberos works.
> > 
> > AD trust is a follows:
> > 
> > # ipa trust-find
> > 
> > 2 trusts matched
> > 
> > Realm name: net.dr.dk
> > Domain NetBIOS name: NET
> > Domain Security Identifier: S-1-5-21-x--
> > 
> > Realm name: place.dr.dk
> > Domain NetBIOS name: PLACE
> > Domain Security Identifier: S-1-5-21-xx-xx-xxx
> > Trust type: Active Directory domain
> > 
> > Number of entries returned 2
> > 
> > 
> > # ipa trust-show place.dr.dk
> > Realm name: place.dr.dk
> > Domain NetBIOS name: PLACE
> > Domain Security Identifier: S-1-5-21---x
> > Trust direction: Trusting forest
> > Trust type: Active Directory domain
> > 
> > # ipa trust-show net.dr.dk
> > Realm name: net.dr.dk
> > Domain NetBIOS name: NET
> > Domain Security Identifier: S-1-5-21-x--xx
> > 
> > users are located in net.dr.dk.
> > 
> > > From looking at the doc's this should just work... However, can't get
> > > it to work. Am I missing something?
> Make screenshots of PuTTY screens showing what you configured and what
> does not work. You can also ask PuTTY to generate logs.

Additionally please check the klist output on the Windows client. It
should show the host principal of the Linux client
(host/client.ipa.domain@IPA.DOMAIN). If the principal is there the sshd
logs on the Linux client with a high debug level might also have some
hints why GSSAPI authentication failed.

HTH

bye,
Sumit

> 
> -- 
> / Alexander Bokovoy
> 
> -- 
> 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

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

Re: [Freeipa-users] SSH login using putty from Windows to SSSD client in IPA AD trust

[Sumit Bose]

On Wed, Sep 07, 2016 at 09:55:45AM +0200, Troels Hansen wrote:
> 
> 
> - On Sep 7, 2016, at 9:43 AM, Sumit Bose sb...@redhat.com wrote:
> 
> > Additionally please check the klist output on the Windows client. It
> > should show the host principal of the Linux client
> > (host/client.ipa.domain@IPA.DOMAIN). If the principal is there the sshd
> > logs on the Linux client with a high debug level might also have some
> > hints why GSSAPI authentication failed.
> > 
> 
> 
> Hmm, no host tickets. Only krbtgt for the domain and LDAP and CIFS principal 
> for thc DC's

So I guess there is no cross-realm ticket either, i.e.
krbtgt/IPA.DOMAIN@AD.DOMAIN. Can you check on AD if the IPA DNS domain
is listed in the 'Name Suffix Routing' tab in the trust properties of
the IPA domain? Additionally please check if the DNS SRV records like
e.g. _kerberos._udp.ipa.domain can be resolved on the AD side.

HTH

bye,
Sumit

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

Re: [Freeipa-users] sss / nsswitch

[Sumit Bose]

On Tue, Sep 13, 2016 at 08:51:48AM +0200, Rob Verduijn wrote:
> Hi all,
> 
> Yesterday my fedora 24 box received an update for sssd to 1.14.1-2.fc24.
> 
> Then after the reboot the nfs-idmap service told me it couldn't start
> because it could not find method sss.
> 
> So I filed a bug report and tried switching the method nsswitch.
> 
> But now all files on my kerberos nfs4 shares belong to nobody:nobodyy again.
> 
> Anybody who has a tip on how to work around this until they fix sssd ?

The module got its own sub-package. Please install sssd-nfs-idmap.

HTH

bye,
Sumit

> 
> Cheers
> Rob Verduijn

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

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

Re: [Freeipa-users] sss / nsswitch

[Sumit Bose]

On Tue, Sep 13, 2016 at 10:13:12AM +0200, Rob Verduijn wrote:
> Hi,
> 
> Thanks that did it.
> 
> Is there a less painfull way to be notified of these changes ?
> 
> My nfs configuration gets broken much more than I like because of changes
> like these.
> I know fedora is supposed to be testing grounds unstable software, but I
> would really like to hear a heads up more often.

The change was mentioned in the upstream release notes of SSSD-1.14.1
https://fedorahosted.org/sssd/wiki/Releases/Notes-1.14.1 but of course I
cannot be expected to read all upstream release note before running 'dnf
update'. 

The change was necessary because before the plugin was in the
sssd-common package and this caused that some nfs dependencies were
pulled in even on systems where nfs is not needed at all. Since neither
SSSD nor nfs-idmap strictly require the plugin the new package is not
automatically installed during update.

bye,
Sumit

> 
> Rob Verduijn
> 
> 2016-09-13 9:03 GMT+02:00 Sumit Bose :
> 
> > On Tue, Sep 13, 2016 at 08:51:48AM +0200, Rob Verduijn wrote:
> > > Hi all,
> > >
> > > Yesterday my fedora 24 box received an update for sssd to 1.14.1-2.fc24.
> > >
> > > Then after the reboot the nfs-idmap service told me it couldn't start
> > > because it could not find method sss.
> > >
> > > So I filed a bug report and tried switching the method nsswitch.
> > >
> > > But now all files on my kerberos nfs4 shares belong to nobody:nobodyy
> > again.
> > >
> > > Anybody who has a tip on how to work around this until they fix sssd ?
> >
> > The module got its own sub-package. Please install sssd-nfs-idmap.
> >
> > HTH
> >
> > bye,
> > Sumit
> >
> > >
> > > Cheers
> > > Rob Verduijn
> >
> > > --
> > > 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
> >
> > --
> > 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
> >

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

Re: [Freeipa-users] In webgui, ID Views slow, to crashingly slow

[Sumit Bose]

On Tue, Sep 20, 2016 at 09:33:21AM +0300, Alexander Bokovoy wrote:
> On Tue, 20 Sep 2016, Martin Babinsky wrote:
> > On 09/20/2016 12:17 AM, Simpson Lachlan wrote:
> > > > -Original Message-
> > > > 
> > > > On 09/19/2016 03:12 AM, Lachlan Musicman wrote:
> > > > > Hi
> > > > > 
> > > > > Sometimes when I visit the ID Views page in the webgui, it is
> > > > > crushingly slow, and often it times out.
> > > > > 
> > > > > Centos 7, ipa --version
> > > > > VERSION: 4.2.0, API_VERSION: 2.156
> > > > > 
> > > > > Is there a reason, can I do something to fix this?
> > > > > 
> > > > 
> > > > What kind of ID Views do you use? Do you use them to  override AD users?
> > > > Is there any useful info in '/var/log/httpd/error_log'?
> > > 
> > > There is the single ID View Name, Default Trust View, and in that we have 
> > > a number of users over riding the AD usernames and home dirs.
> > > 
> > > The httpd error log is relatively large, tbh, but there's nothing in 
> > > there that looks like an obvious reason. In fact, for an error log, there 
> > > is a hell of a lot of "SUCCESS" messages? The most obvious culprit in the 
> > > error log is jsonserver_session...
> > > 
> > > Next time I see it (I only see it intermittently), I'll grab the logs and 
> > > have a look.
> > > 
> > > Cheers
> > > L.
> > > 
> > > 
> > > 
> > > This email (including any attachments or links) may contain
> > > confidential and/or legally privileged information and is
> > > intended only to be read or used by the addressee.  If you
> > > are not the intended addressee, any use, distribution,
> > > disclosure or copying of this email is strictly
> > > prohibited.
> > > Confidentiality and legal privilege attached to this email
> > > (including any attachments) are not waived or lost by
> > > reason of its mistaken delivery to you.
> > > If you have received this email in error, please delete it
> > > and notify us immediately by telephone or email.  Peter
> > > MacCallum Cancer Centre provides no guarantee that this
> > > transmission is free of virus or that it has not been
> > > intercepted or altered and will not be liable for any delay
> > > in its receipt.
> > > 
> > 
> > One thing that crossed my mind is to check the connectivity to the AD
> > domain controllers. To resolve AD user overrides, FreeIPA uses SSSD to
> > contact AD DCs to do the username -> SID translation. If there is some
> > problem contacting them, then there may be hangs/timeouts when resolving
> > override anchors.
> Internally IPA framework attempts to resolve ID override anchors. We can
> actually optimize this code as ipaOriginalUID attribute contains
> normalized name already, written their when the override is created and
> never changed afterwards. This should speed up the resolution of large
> overrides.
> 
> Martin, can you file a ticket for that? The code in question is
> baseidoverride.convert_anchor_to_human_readable_form() which could
> benefit from passing in entry_attrs and checking ipaoriginaluid there.
> If 'ipaoriginaluid' is missing, do analysis of ipaanchoruuid like it is
> done now.

As an alternative I wonder if the WebUI can be made asynchronous in the
sense that it displays the raw data (the SID in this case) first and run
the lookups in the background and replace the SID when the name is
available. I've seen some Windows tools behaving this when looking up
large numbers of SIDs.

bye,
Sumit

> 
> -- 
> / Alexander Bokovoy
> 
> -- 
> 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

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

Re: [Freeipa-users] SSH public user's key stored in AD POSIX attribute

[Sumit Bose]

On Wed, Sep 21, 2016 at 09:47:12AM +0200, Jan Karásek wrote:
> Hi, 
> 
> I have a question about the IPA-AD trust scenario where POSIX attributes are 
> store in AD. 

Although I describe some possible solution below I wonder if using IPA
overrides which allow to add public ssh keys for AD user would work for
you as well? 

> 
> I would like to know if it's possible to store public SSH user key in Active 
> Directory in some user's object attribute - the same way as uidNumber or 
> loginShell. I can't find any suitable attribute for ssh in AD schema but the 
> uidNumber,gidNumber and others are already presented (win2012). 

In general it is possible either extend the schema or use an existing
attribute, see e.g.
https://social.technet.microsoft.com/Forums/en-US/8aa28e34-2007-49fe-a689-e28e19b2757b/is-there-a-way-to-link-ssh-key-in-ad?forum=winserverDS
for details.

But given the recent activities in areas of Powershell and OpenSSH for
Windows I wonder if there might be some "official" attributes coming
sooner or later. Currently I'm not aware of any plans here but maybe
other readers on the list have more insight here?

> 
> So is there any chance to extend AD schema and let the IPA server get public 
> ssh user's key from AD the same way as other POSIX attributes ? Is it IPA 
> ready for that and how that attribute should be named in AD ? 

You have to configure SSSD on the IPA server to read the attribute and
forward it to the clients, for this you need (at least) to add

[domain/EXAMPLE]
ldap_user_extra_attrs = adAttributeName:sshPublicKey

(see sssd-ldap man page for details)

bye,
Sumit

> 
> Thanks, 
> 
> Jan 

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

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

Re: [Freeipa-users] key + 2FA (password+OTP) is not working

[Sumit Bose]

On Thu, Sep 22, 2016 at 08:17:21AM +, Deepak Dimri wrote:
> Hi All,
> 
> 
> I am trying hard to get my 2FA working with FreeIPA but every effort of mine 
> going waste! I have referred earlier forum emails but could not find any good 
> reply on the issue i am facing.
> 
> 
> This is what i am trying
> 
> 
> I have a test user created in my IPA server enabled with Two factor 
> authentication (password + OTP) and has ssh public key added in its profile.  
> I want this test user to ssh into my ipa client (ubuntu 14.04) using  key + 
> password + OTP. I woudl ceryainly prefer just the key+  OTP only ( no 
> password) but that seems far sighted as i cannot even make it work with what 
> it supposed to work password + OTP.
> 
> 
> My /etc/ssh/sshd_conf file has almost everything default  except i added 
> these two lines at the end of it
> 
> Match Group testusergroup
> 
>AuthenticationMethods publickey,password:pam 
> publickey,keyboard-interactive:pam
> 
> i also tried with below but no luck
> 
> Match Group testusergroup
> 
>  AuthenticationMethods publickey,keyboard-interactive
> 
> 
> my /etc/pam.d/sshd has these two changes, rest i kept default:
> 
> 
> # Standard Un*x authentication.
> 
> #@include common-auth
> 
> 
> auth required pam_sss.so
> 
> 
> Now when i try to ssh into ipa client i either keep getting promptS for the 
> password or it gets into a loop asking me to change the password ;complaining 
> falsely that it has expired. I have tried multiple combinations of 
> configurations by referring earlier email threads but none i found helpful. I 
> cant make simple 2FA login to work with freeIPA. Normal password and key 
> works just fine. its the 2FA which does not work for me.
> 
> 
> Would really be thankful if some one can help me with this issue.. is there 
> any good freeIPA 2FA configuration document that i can refer?

Please add debug_level=10 to the [pam] and [domain/...] section of
sssd.conf, restart SSSD, re-run the authentication and send the
generated debug logs together with your sssd.conf and the full
/etc/pam.d/sshd. Please see
https://fedorahosted.org/sssd/wiki/Troubleshooting for details.

> 
> What should the steps for it work seamlessly?

In general it should work out of the box with SSSD's ipa provider.

bye,
Sumit

> 
> 
> Many Thanks,
> 
> Deepak
> 

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

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

Re: [Freeipa-users] SSH using putty to IPA client

[Sumit Bose]

On Mon, Sep 26, 2016 at 09:25:46AM +0200, Troels Hansen wrote:
> After we installed a new set of IPA servers for prod, and joined AD using 
> username and password to have AD create a correct suffix routing everythin 
> seems to work, and the suffix routing is created correctly on AD. 
> 
> However, trying to SSH from Windows using Putty and kerberos fails: 
> 
> Putty log shows: 
> Event Log: GSSAPI authentication initialisation failed 
> Event Log: No authority could be contacted for authentication.The domain name 
> of the authenticating party could be wrong, the domain could be unreachable, 
> or there might have been a trust relationship failure. 
> 
> DNS is on AD (manually added, and IPA have no DNS installed. 
> 
> Kerberos DNS is correct: 
> 
> # dig _kerberos._tcp.lx.dr.dk SRV 
>  
> ;; ANSWER SECTION: 
> _kerberos._tcp.lx.dr.dk. 3600 IN SRV 0 100 88 ipa01.lx.dr.dk. 
> _kerberos._tcp.lx.dr.dk. 3600 IN SRV 0 100 88 ipa02.lx.dr.dk. 
> 
> ;; ADDITIONAL SECTION: 
> ipa01.lx.dr.dk. 3600 IN A x.y.z.135 
> ipa02.lx.dr.dk. 3600 IN A x.y.z.134 
> 
> 
> # dig _kerberos._tcp.dc._msdcs.lx.dr.dk SRV 
> ... 
> ;; ANSWER SECTION: 
> _kerberos._tcp.dc._msdcs.lx.dr.dk. 3600 IN SRV 0 100 88 ipa02.lx.dr.dk. 
> _kerberos._tcp.dc._msdcs.lx.dr.dk. 3600 IN SRV 0 100 88 ipa01.lx.dr.dk. 
> 
> ;; ADDITIONAL SECTION: 
> ipa02.lx.dr.dk. 3600 IN A x.y.z.134 
> ipa01.lx.dr.dk. 3600 IN A x.y.z.135 
> 
> 
> Klist on Windows shows I have a TGT for the LX domain (but only a TGT), sorry 
> for the danish. 
> 
> #0> Klient: drextrha @ NET.DR.DK 
> Server: krbtgt/LX.DR.DK @ PLACE.DR.DK 
> KerbTicket-krypteringstype: AES-256-CTS-HMAC-SHA1-96 
> Billetflag 0x40a5 -> forwardable renewable pre_authent ok_as_delegate 
> name_canonicalize 
> Starttidspunkt: 9/21/2016 14:58:36 (lokal) 
> Sluttidspunkt: 9/21/2016 23:16:09 (lokal) 
> Fornyelsestidspunkt: 9/28/2016 13:16:09 (lokal) 
> Sessionsnøgletype: AES-256-CTS-HMAC-SHA1-96 
> 
> 
> I can't see whats wrong and can't seem to find out whats wrong? 
> Suggestions welcome :-) 

Have you checked the firewalls? AD clients must be able to talk to the
KDC port (88 udp and tcp) on the IPA servers to get service tickets for
IPA hosts.

HTH

bye,
Sumit

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

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

Re: [Freeipa-users] SSH using putty to IPA client

[Sumit Bose]

On Mon, Sep 26, 2016 at 01:11:49PM +0200, Troels Hansen wrote:
> 
> 
> - On Sep 26, 2016, at 10:18 AM, Sumit Bose sb...@redhat.com wrote:
> 
> > 
> > Have you checked the firewalls? AD clients must be able to talk to the
> > KDC port (88 udp and tcp) on the IPA servers to get service tickets for
> > IPA hosts.
> > 
> 
> 
> KDC ports seems to work  Besides, I don't have a TGT for the IPA (LX) 
> domain, untill I try to SSH to it. I guess I shouldn't be able to if KDC 
> traffic was blocked?

The cross-realm TGT 'krbtgt/LX.DR.DK @ PLACE.DR.DK' is issued by the AD
DC. So this is not indication that the IPA KDC can be reached by the AD
client.

Do you see and log messages in the krb5kdc.log on the IPA server? If it
is not the firewall I would suggest to record the IP traffic of the AD
client and check what it tries to do after the AD DC send the
cross-realm TGT.

About the DNS SRV records, did you add matching records for _udp as
well? I'm not sure if the AD client will fallback to _tcp if they are
missing or just stop?

HTH

bye,
Sumit

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

Re: [Freeipa-users] SSH using putty to IPA client

[Sumit Bose]

On Wed, Sep 28, 2016 at 09:19:37AM +0200, Troels Hansen wrote:
> 
> 
> - On Sep 26, 2016, at 1:30 PM, Sumit Bose sb...@redhat.com wrote:
> 
> > About the DNS SRV records, did you add matching records for _udp as
> > well? I'm not sure if the AD client will fallback to _tcp if they are
> > missing or just stop?
> > 
> 
> 
> Ok, finally got some time to debug this.
> 
> tcpdump'ing in the IPA server and logging in, and analyzing the traffic in 
> wireshark I can see that some KRB5KDC_ERR_PREAUTH_REQUIRED traffic to both of 
> the KDC's as expected, followed by some AS-REQ and AS-REP, finally followed 
> by KRB5KRB_ERR-RESPONSE_TOO_BIG, source MAC is a Cisco router despite the 
> server being HP, so somewhere in the network a Cisco router is breaking our 
> Kerberos.

KRB5KRB_ERR-RESPONSE_TOO_BIG is an expected return code here. The
Kerberos communication is typically started via UDP. But the PAC data in
the ticket is typically larger than a single UPD packet. The KDC tells
the client wit KRB5KRB_ERR-RESPONSE_TOO_BIG to switch to tcp so that the
response can be reliably send in multiple tcp packets. If
KRB5KRB_ERR-RESPONSE_TOO_BIG is the last you see on the wire I would
suspect that port 88 tcp is blocked somewhere.

HTH

bye,
Sumit

> 
> I'll start hunting a solution somewhere else but IPA..

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