[Freeipa-users] anonymous binds limits?

[Janelle]

Hello,

Just wondering if there is an easy way to increase anonymous binds on 
the back end for non Kerberos clients?
I have seen some mention of it, and that IPA has limits, can't can't 
find a lot of detail?


Thank you
~J

--
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] subjectAlternitiveName for webservice

[Matt .]

Hi Rob,

Thanks for the explanation. I understand your solution, I just thought
that was "the dirty" way :)

Thanks for your effort!

Cheers,

Matt

2015-03-27 18:57 GMT+01:00 Rob Crittenden :
> Matt . wrote:
>> I'm almost there but what happens when I regenerate a certificate for
>> the ldap server I get the following when I visit it through the
>> loadbalancer:
>>
>> no alternative certificate subject name matches target host name
>> 'ldap-01.domain'
>>
>> I think this is strange as the certificate shows the ldap under the
>> altnames for HTTP/ldap-01 but there is indeed no ldap-01 as altname
>> but only on the certificate itself.
>
> It turns out that NSS implements cert checking very strictly following
> RFC 2818 while OpenSSL is a bit more lax about it.
>
> The RFC states that if there is a subjectAltName then only that is used
> to validate the hostname. And in fact, it discourages using the subject
> at all and ONLY relying on the subjectAltName, though it does recognize
> that it is current practice (and was that way in 2000 as well).
>
> So you need to request your new cert with TWO names: the host name and
> the alternate name. That should make the cert work anyway.
>
> rob
>
>>
>>
>>
>> 2015-03-26 16:48 GMT+01:00 Rob Crittenden :
>>> Matt . wrote:
 HI Rob,

 Yes something is wrong there I guess.
>>>
>>> In any case, it doesn't apply to what you're trying to do.
>>>
 But still, I actually need to add a SAN to the webserver cert, which
 is different I think than the services at least.

 So the question there is... how ?
>>>
>>> What webserver cert? Are you trying to load balance the IPA services via
>>> DNS?
>>>
>>> Not knowing what you want, I'm just answering what you are ASKING. That
>>> is not the same as giving a proper answer. I have the feeling you want
>>> to load balance IPA in general which isn't going to work without a ton
>>> of (ongoing) manual effort. Even Microsoft recommends against trying
>>> this in its AD environment: http://support.microsoft.com/en-us/kb/325608
>>>
>>> In any case, the instructions I've already provided still apply.
>>>
>>> If you want to replace the Apache webserver cert you'll just need to do
>>> a couple of things first which has the potential of completely breaking
>>> IPA, so you'll need to be careful.
>>>
>>> Before you do anything, backup *.db in /etc/httpd/alias.
>>>
>>> Stop tracking the Apache cert in certmonger:
>>>
>>> # ipa-getcert stop-tracking -d /etc/httpd/alias -n Server-Cert
>>>
>>> Delete the existing cert:
>>>
>>> # certutil -D -d /etc/httpd/alias -n Server-Cert
>>>
>>> Like I said, destructive.
>>>
>>> Finally use certmonger to get a new cert that includes a SAN. The syntax
>>> is slightly different than before, mostly because I'm just guessing in
>>> the dark because you aren't including enough details into what you're
>>> trying.
>>>
>>> # ipa-getcert -d /etc/httpd/alias -n Server-Cert -N CN=ipa1.example.com
>>> -K HTTP/ipa1.example.com -D ipa.example.com -p /etc/httpd/alias/pwdfile.txt
>>>
>>> In this case the IPA server is ipa1.example.com and you're creating a
>>> SAN for ipa.example.com.
>>>
>>> Restart httpd.
>>>
>>> Note that this doesn't solve the Kerberos problem so cli access will
>>> still not work as expected. The UI _might_ work using forms-based
>>> authentication.
>>>
>>> I'd strongly urge you to think about the top of this e-mail before
>>> proceeding onto the bottom.
>>>
>>> rob
>>>

 Cheers,

 Matt

 2015-03-26 14:50 GMT+01:00 Rob Crittenden :
> Matt . wrote:
>> When digging around I see this documentation:
>>
>> http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/load-balancing.html
>>
>> I would except that server.example.com is not going to be accepted by
>> IPA when you visit the webgui like that ?
>
> These are SRV records for the ldap service. Think of it as discovery for
> who provides ldap service in the domain. It isn't something used by a
> web browser.
>
> I'm no DNS expert (by far) but this example looks a little wonky. I'd
> think it should be example.com and not server.example.com. But in any
> case it is irrelevant to a browser.
>
> 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] Need to replace cert for ipa servers

[sipazzo]

Rob, thank you,you have been so helpful. This appears to have worked in my 
sandbox environment. I was able to get the new certs for the directory server 
and apache, stop tracking and remove the old Go Daddy certs, put my original CA 
certs in the correct locations and import into the databases, then configure 
the services to use them. I am going to move some clients into sandbox next 
week(we have rhel5, 6 and SOlaris)and see how they handle the new config before 
rolling out to prod environment and other ipa servers.

Thank you for everything.

On Wed, 3/25/15, Rob Crittenden  wrote:

 Subject: Re: [Freeipa-users] Fw: Need to replace cert for ipa servers
 To: "sipazzo" , "freeipa-users@redhat.com" 

 Date: Wednesday, March 25, 2015, 2:43 PM
 
 sipazzo wrote:
 > Ok I finally was able to get a sandbox
 environment up to test the cert
 >
 replacement. When I ran this stepgot to the cert request
 steps:
 > ipa-getcert request -d
 /etc/dirsrv/slapd-IPADOMAIN-COM -n Server-Cert -p
 >
 /etc/dirsrv/slapd-IPADOMAIN-COM/pwdfile.txt -C
 >
 '/usr/lib64/ipa/certmonger/restart_dirsrv
 IPADOMAIN-COM' -N
 >
 CN=idm2-corp.ipadomain.com -K ldap/ipa2-corp.ipadomain@ipadomain.com
 > 
 > I got a message
 saying the cert at same location is already used by
 > request with nickname
 "20140729215511" , same when I ran it for
 > /etc/httpd/alias. I continued on anyway
 but when I get to this step:
 
 You need to tell certmonger to stop tracking
 the existing GoDaddy certs,
 not that they
 would have been renewable anyway.
 
 You may also need to remove them from the NSS
 database(s) using
 something like:
 
 # certutil -D -n
 'nickname' -d /path/to/db
 
 I think the subject will be different enough
 that it may be ok as-is.
 
 The other errors are due to the fact that no
 certificate was issued.
 
 rob
 
 > 
 >  # certutil -V -u V -n Server-Cert -d
 /etc/dirsrv/slapd-EXAMPLE-COM
 > 
 > I get an error:
 >
 certutil: could not find certificate named
 "Server-Cert":
 >
 PR_FILE_NOT_FOUND_ERROR: File not found
 >
 
 > Although running certutil -L -d
 /etc/dirsrv/slapd-IPADOMAIN-COM/,
 >
 returns this:
 > 
 >
 Certificate Nickname                         
                Trust
 >
 Attributes
 >                   
                                      
    
 > SSL,S/MIME,JAR/XPI
 > 
 > GD_CA         
                                        
       CT,C,C
 > IPADOMAIN.COM IPA CA 
                                    
 CT,,
 > NWF_GD                 
                                  
    u,u,u
 > 
 > 
 > Showing that the IPA
 Dogtag cert is now listed whereas it was not
 > previously. 
 > 
 > 
 >
 
 > *From:* sipazzo 
 > *To:* Rob Crittenden ;
 "freeipa-users@redhat.com"
 > 
 > *Sent:* Friday, March 13, 2015 1:32 PM
 > *Subject:* Re: [Freeipa-users] Fw: Need to
 replace cert for ipa servers
 > 
 > This environment is over 350 servers, many
 of which are in production so
 > I may
 have to wait a bit for change management approval to attempt
 to
 > resolve this issue, particularly if
 you think it might break something. 
 > I
 will keep you updated on my progress. Thank you much.
 > 
 > 
 > 
 >
 
 > *From:* sipazzo 
 > *To:* Rob Crittenden 
 > *Cc:* "freeipa-users@redhat.com"
 
 > *Sent:* Friday, March 13, 2015 9:21 AM
 > *Subject:* Re: [Freeipa-users] Fw: Need to
 replace cert for ipa servers
 > 
 > 
 > 
 > 
 > 
 > -Original Message-
 > From: freeipa-users-boun...@redhat.com
 > 
 > [mailto:freeipa-users-boun...@redhat.com
 > ]
 On Behalf Of Rob Crittenden
 > Sent:
 Thursday, March 12, 2015 1:52 PM
 > To:
 sipazzo; freeipa-users@redhat.com
 
 > Subject: Re: [Freeipa-users] Fw: Need to
 replace cert for ipa servers
 > 
 > sipazzo wrote:
 >> I
 do have other CAs (just not the master but it is available
 offline
 >> if
 >>
 needed)
 > 
 > To be
 clear, all IPA servers are masters, some just run more
 services
 > than others. It sounds like
 you have at least one CA available which
 > should be sufficient.
 >
 
 >> Directory server is running
 >> The apache web server is running and I
 can get to the gui ipa
 >> cert-show 1
 works
 > 
 > Ok. I guess
 the place to start is to get certs for Apache and 389-ds,
 > then we can see about using these new
 certs.
 > 
 > In the
 thread you showed that the IPA 389-ds doesn't have a
 Server-Cert
 > nickname. You'll want
 to do the same for /etc/httpd/alias before running
 > the following commands otherwise you could
 end up with non-functional
 > server.
 > 
 > These should get IPA
 certs for 389-ds and Apache. You'll need to edit
 > these commands to match your
 environment:
 > 
 > #
 ipa-getcert request -d /etc/httpd/alias -n Server-Cert -p
 > /etc/httpd/alias/pwdfile.txt -C
 /usr/lib64/ipa

Re: [Freeipa-users] using dogtag outside of freeIPA?

[Dmitri Pal]

On 03/27/2015 04:52 PM, Steve Neuharth wrote:

Hello,

Is it possible or perhaps not recommended to use the dogtag API and/or 
UI on a FreeIPA system without using the freeIPA CLI or UI? I have a 
requirement to submit a certificate to a service without kerberos and 
without client software installed using a RESTful API. Dogtag API is 
very well documented and I do not want to associate all my 
certificates with a Kerberos principal because it adds complexity to 
the cert signing process. I just need to sign a cert without the 
FreeIPA overhead.


I tried to get to the Dogtag web UI through the url 
http://ipa.example.com/ca/ee/ca but I get an unauthenticated web page 
(no password prompt) and broken image links. This tells me that 
perhaps the Dogtag UI in a FreeIPA installation is not meant to be 
used without FreeIPA. Is that correct?


I know this is a weird use case and not necessarily a FreeIPA problem 
but if someone could advise, I'd greatly appreciate it.


For now you should use Dogtag by itself for this use case without IPA.
We are working on making it easier for this use case to be possible via 
IPA but it is not there yet.



--steve





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

Re: [Freeipa-users] Understanding the migration mode

[Dmitri Pal]

On 03/27/2015 01:20 PM, Prasun Gera wrote:



Keys can be generated in migration in two ways: by the migration
web UI
or by sssd. I'm guessing you were unaware of this second method
and that
is how the keys are being created.


That's what I suspected too. But it doesn't look like SSSD is 
generating keys. At least not right away. I SSHed to one of the 
clients with ipa-client installed as well as to the ipa-server, and 
that didn't change anything right away. That's what I was trying to 
figure out. i.e Which event triggers key generation ?


I'd suggest using nss_ldap over NIS. You can also manually configure
Kerberos and have basic functionality as long as nscld doesn't
drive you
crazy.


Thanks. I'll look into it.


It's not the encryption type, it is how it is encoded in 389-ds. When
you migrated the passwords they were stored as {crypt}hash. When the
password is changed in 389-ds it becomes {SSHA}hash. The NIS
configuration for slapi-nis only provides those passwords prefixed
with
{crypt} (because NIS can only grok that format). 



rob


Yeah that sounds like a possible fix, although a less than ideal one. 
Is it possible to change it back to {SSHA} after all the clients have 
been migrated suitably ? How would one force all the existing users' 
passwords to be converted to {SSHA} once slapi-nis is no longer needed ?




The idea is that you tel lall the users to either login via migration 
page or via SSSD.
If your server is in a migration mode the migration page should be 
available and SSSD should detect that server is in migration mode.
In this case any authentication via SSSD will end up creating proper 
hashes for Kerberos. I suspect this is when the conversion of the LDAP 
hashes happens too.
You suggested that this is not the case but I am not sure that the test 
was 100 correct.


Please try:
- check that migration mode is on
- check that user does not have kerberos password only LDAP hash from 
NIS migration

- ssh into a box that runs SSSD with such user, authenticate
As a result you should see Kerberos hash created for this user and I 
suspect the LDAP hash is converted at the same time.



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

[Freeipa-users] using dogtag outside of freeIPA?

[Steve Neuharth]

Hello,

Is it possible or perhaps not recommended to use the dogtag API and/or UI
on a FreeIPA system without using the freeIPA CLI or UI? I have a
requirement to submit a certificate to a service without kerberos and
without client software installed using a RESTful API. Dogtag API is very
well documented and I do not want to associate all my certificates with a
Kerberos principal because it adds complexity to the cert signing process.
I just need to sign a cert without the FreeIPA overhead.

I tried to get to the Dogtag web UI through the url
http://ipa.example.com/ca/ee/ca but I get an unauthenticated web page (no
password prompt) and broken image links. This tells me that perhaps the
Dogtag UI in a FreeIPA installation is not meant to be used without
FreeIPA. Is that correct?

I know this is a weird use case and not necessarily a FreeIPA problem but
if someone could advise, I'd greatly appreciate it.
--steve
-- 
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] Fwd: Unexpected IPA Crashes

[Dmitri Pal]

On 03/27/2015 11:32 AM, Sankar Ramlingam wrote:

On 03/27/2015 01:42 PM, David Kreuter wrote:
No, there are no entries with "segfaulter" neither in 
/var/log/messags nor in journalctr.


Meanwhile we encountered several directory server hangs and I was 
able to produce the stacktrace. Perhpas you can have a look.

Hi David,
You seem to have the latest/released version of 389-ds-base. You 
can probably try an upgrade to get the latest of other dependent 
components and 389-ds-base-debuginfo.


Yes. Please add this package and try to capture the stack trace again.
We will then be able to see where the issue is.



Thanks,
-Sankar R.




*From: *"David Kreuter" 
*To: *"freeipa-users" 
*Sent: *Thursday, 26 March, 2015 11:18:59 PM
*Subject: *Unexpected IPA Crashes

We have been using FreeIPA since two years and were more than happy. 
But since two weeks we are facing unexpected crashed and can not 
really debug the strange behaviours. The crashes are definitely not 
caused by connecting a new system or changing the LDAP schema 
heavily. Following IPA is used:


Name: ipa-server

Arch: x86_64

Version : 3.3.3

Release : 28.0.1.el7.centos.3

Size: 4.1 M


I have followed the troubleshooting guide 
http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#Troubleshooting 
and activated logging and activated the core dumping. Unfortunately, 
I cannot provide you any core dump, because it is not created after 
the ipa servers crashes. I'm sure the dirsrv is causing the problem, 
because when i restart the 389, then ipa works fine for a while. 
Currently I have activated the replication log level 8192. The error 
log shows no suspicious error or any fatal error. Following 389* 
versions are used:



Installed Packages

389-ds-base.x86_64 1.3.3.1-15.el7_1   
@/389-ds-base-1.3.3.1-15.el7_1.x86_64


389-ds-base-debuginfo.x86_64 1.3.1.6-26.el7_0   @base-debuginfo

389-ds-base-libs.x86_64 1.3.3.1-15.el7_1


Can you please provide some hint how I can debug this problem in more 
detail. Btw, the ipa infrastructure consist of one master and one 
replica. The server was also crashing, when the replica server was 
turned off. Do you thing an upgrade would solve the problem as the 
last resort?













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

Re: [Freeipa-users] How to add 'generic' service?

[Simo Sorce]

On Fri, 2015-03-27 at 15:33 -0400, Coy Hile wrote:
> I’m rebuilding my existing heimdal realm using FreeIPA, and right now
> I’m having difficulty creating the service principal
> afs/realm-name@REALM. When I use ipa service-add, I get output thusly:
> 
> [root@ipa-us-east-2 ~]# ipa service-add afs/coyhile@coyhile.com
> ipa: ERROR: The host 'coyhile.com' does not exist to add a service to.
> [root@ipa-us-east-2 ~]# ipa service-add afs/coyhile@coyhile.com --force
> ipa: ERROR: The host 'coyhile.com' does not exist to add a service to.
> 
> It’s an arbitrary principal; it really shouldn’t matter…

We should probably add a RFE to decide how to handle/support these cases
officially, but see later.

> So, being a knowledgable administrator of both MIT and Heimdal KDCs, I
> decided to break out kadmin.
> 
> 
> kadmin.local:  ank -randkey -e aes256-cts:normal
> afs/coyhile@coyhile.com
> WARNING: no policy specified for afs/coyhile@coyhile.com;
> defaulting to no policy
> add_principal: Kerberos database constraints violated while creating
> "afs/coyhile@coyhile.com”.

Our DAL plugin, normally, prevents you from adding principals via the
kadmin interface because kadmin does not know how to create a properly
functional user or service object. It would also create them in the
wrong place (under cn=kerberos,).

> This brings up two questions:
> 
> Firstly, is there some secret sauce I have to use to make ipa do my
> bidding here?

Glad you asked, there actually is an non orthodox, non supported, secret
way :-)
But use it only for principals you know are really not user principals
or normal service principals.

The trick is to use kadmin.local with the switch:
  -x ipa-setup-override-restrictions


> On a related note is there a way to restrict enctypes?

Yes, you can do that by setting the appropriate supported and default
enctypes in LDAP. They are in cn=YOUR.REALM,cn=kerberos, in the
attributes krbDefaultEncSaltTypes and krbSupportedEncSaltTypes

Unfortunately we do not expose this configuration via the UI.

>   Since everything that I’m dealing with is either recent Linux,
> recent Illumos, or (gag!) sufficiently recent Windows, I’d like to
> restrict everything to AES only and get rid of des3 and arcfour-hmac.

Good idea, in the IETF Kitten WG we are also starting the process to
deprecate RC4 and 3DES and we have a ticket to stop using them by
default in FreeIPA too: https://fedorahosted.org/freeipa/ticket/4740

HTH,
Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
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 add 'generic' service?

[Rob Crittenden]

Coy Hile wrote:
> I’m rebuilding my existing heimdal realm using FreeIPA, and right now I’m 
> having difficulty creating the service principal afs/realm-name@REALM. When I 
> use ipa service-add, I get output thusly:
> 
> [root@ipa-us-east-2 ~]# ipa service-add afs/coyhile@coyhile.com
> ipa: ERROR: The host 'coyhile.com' does not exist to add a service to.
> [root@ipa-us-east-2 ~]# ipa service-add afs/coyhile@coyhile.com --force
> ipa: ERROR: The host 'coyhile.com' does not exist to add a service to.
> 
> It’s an arbitrary principal; it really shouldn’t matter…

You need to create the host coyhile.com first.  

> So, being a knowledgable administrator of both MIT and Heimdal KDCs, I 
> decided to break out kadmin.
> 
> 
> kadmin.local:  ank -randkey -e aes256-cts:normal afs/coyhile@coyhile.com
> WARNING: no policy specified for afs/coyhile@coyhile.com; defaulting to 
> no policy
> add_principal: Kerberos database constraints violated while creating 
> "afs/coyhile@coyhile.com”.

Probably same reason. We don't recommend using kadmin.local in general.

> 
> This brings up two questions:
> 
> Firstly, is there some secret sauce I have to use to make ipa do my bidding 
> here?  On a related note is there a way to restrict enctypes?  Since 
> everything that I’m dealing with is either recent Linux, recent Illumos, or 
> (gag!) sufficiently recent Windows, I’d like to restrict everything to AES 
> only and get rid of des3 and arcfour-hmac.

You can manage the default and enabled encryption types in
cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com

I'm not sure if the KDC reads these on the fly so you may want to
restart it after modifying the values.

Or you can control what encryption types are used in keytabs using the
-e option to ipa-getkeytab.

A couple of keytabs are issued during install that will have other keys
so you may want/need to fetch new keytabs if you change the defaults.

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

[Freeipa-users] How to add 'generic' service?

[Coy Hile]

I’m rebuilding my existing heimdal realm using FreeIPA, and right now I’m 
having difficulty creating the service principal afs/realm-name@REALM. When I 
use ipa service-add, I get output thusly:

[root@ipa-us-east-2 ~]# ipa service-add afs/coyhile@coyhile.com
ipa: ERROR: The host 'coyhile.com' does not exist to add a service to.
[root@ipa-us-east-2 ~]# ipa service-add afs/coyhile@coyhile.com --force
ipa: ERROR: The host 'coyhile.com' does not exist to add a service to.

It’s an arbitrary principal; it really shouldn’t matter…

So, being a knowledgable administrator of both MIT and Heimdal KDCs, I decided 
to break out kadmin.


kadmin.local:  ank -randkey -e aes256-cts:normal afs/coyhile@coyhile.com
WARNING: no policy specified for afs/coyhile@coyhile.com; defaulting to no 
policy
add_principal: Kerberos database constraints violated while creating 
"afs/coyhile@coyhile.com”.

This brings up two questions:

Firstly, is there some secret sauce I have to use to make ipa do my bidding 
here?  On a related note is there a way to restrict enctypes?  Since everything 
that I’m dealing with is either recent Linux, recent Illumos, or (gag!) 
sufficiently recent Windows, I’d like to restrict everything to AES only and 
get rid of des3 and arcfour-hmac.



--
Coy Hile
coy.h...@coyhile.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

Re: [Freeipa-users] subjectAlternitiveName for webservice

[Rob Crittenden]

Matt . wrote:
> I'm almost there but what happens when I regenerate a certificate for
> the ldap server I get the following when I visit it through the
> loadbalancer:
> 
> no alternative certificate subject name matches target host name
> 'ldap-01.domain'
> 
> I think this is strange as the certificate shows the ldap under the
> altnames for HTTP/ldap-01 but there is indeed no ldap-01 as altname
> but only on the certificate itself.

It turns out that NSS implements cert checking very strictly following
RFC 2818 while OpenSSL is a bit more lax about it.

The RFC states that if there is a subjectAltName then only that is used
to validate the hostname. And in fact, it discourages using the subject
at all and ONLY relying on the subjectAltName, though it does recognize
that it is current practice (and was that way in 2000 as well).

So you need to request your new cert with TWO names: the host name and
the alternate name. That should make the cert work anyway.

rob

> 
> 
> 
> 2015-03-26 16:48 GMT+01:00 Rob Crittenden :
>> Matt . wrote:
>>> HI Rob,
>>>
>>> Yes something is wrong there I guess.
>>
>> In any case, it doesn't apply to what you're trying to do.
>>
>>> But still, I actually need to add a SAN to the webserver cert, which
>>> is different I think than the services at least.
>>>
>>> So the question there is... how ?
>>
>> What webserver cert? Are you trying to load balance the IPA services via
>> DNS?
>>
>> Not knowing what you want, I'm just answering what you are ASKING. That
>> is not the same as giving a proper answer. I have the feeling you want
>> to load balance IPA in general which isn't going to work without a ton
>> of (ongoing) manual effort. Even Microsoft recommends against trying
>> this in its AD environment: http://support.microsoft.com/en-us/kb/325608
>>
>> In any case, the instructions I've already provided still apply.
>>
>> If you want to replace the Apache webserver cert you'll just need to do
>> a couple of things first which has the potential of completely breaking
>> IPA, so you'll need to be careful.
>>
>> Before you do anything, backup *.db in /etc/httpd/alias.
>>
>> Stop tracking the Apache cert in certmonger:
>>
>> # ipa-getcert stop-tracking -d /etc/httpd/alias -n Server-Cert
>>
>> Delete the existing cert:
>>
>> # certutil -D -d /etc/httpd/alias -n Server-Cert
>>
>> Like I said, destructive.
>>
>> Finally use certmonger to get a new cert that includes a SAN. The syntax
>> is slightly different than before, mostly because I'm just guessing in
>> the dark because you aren't including enough details into what you're
>> trying.
>>
>> # ipa-getcert -d /etc/httpd/alias -n Server-Cert -N CN=ipa1.example.com
>> -K HTTP/ipa1.example.com -D ipa.example.com -p /etc/httpd/alias/pwdfile.txt
>>
>> In this case the IPA server is ipa1.example.com and you're creating a
>> SAN for ipa.example.com.
>>
>> Restart httpd.
>>
>> Note that this doesn't solve the Kerberos problem so cli access will
>> still not work as expected. The UI _might_ work using forms-based
>> authentication.
>>
>> I'd strongly urge you to think about the top of this e-mail before
>> proceeding onto the bottom.
>>
>> rob
>>
>>>
>>> Cheers,
>>>
>>> Matt
>>>
>>> 2015-03-26 14:50 GMT+01:00 Rob Crittenden :
 Matt . wrote:
> When digging around I see this documentation:
>
> http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/load-balancing.html
>
> I would except that server.example.com is not going to be accepted by
> IPA when you visit the webgui like that ?

 These are SRV records for the ldap service. Think of it as discovery for
 who provides ldap service in the domain. It isn't something used by a
 web browser.

 I'm no DNS expert (by far) but this example looks a little wonky. I'd
 think it should be example.com and not server.example.com. But in any
 case it is irrelevant to a browser.

 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] 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] Understanding the migration mode

[Prasun Gera]

>
> Keys can be generated in migration in two ways: by the migration web UI
> or by sssd. I'm guessing you were unaware of this second method and that
> is how the keys are being created.
>
>
That's what I suspected too. But it doesn't look like SSSD is generating
keys. At least not right away. I SSHed to one of the clients with
ipa-client installed as well as to the ipa-server, and that didn't change
anything right away. That's what I was trying to figure out. i.e Which
event triggers key generation ?



> I'd suggest using nss_ldap over NIS. You can also manually configure
> Kerberos and have basic functionality as long as nscld doesn't drive you
> crazy.
>

Thanks. I'll look into it.


>
> It's not the encryption type, it is how it is encoded in 389-ds. When
> you migrated the passwords they were stored as {crypt}hash. When the
> password is changed in 389-ds it becomes {SSHA}hash. The NIS
> configuration for slapi-nis only provides those passwords prefixed with
> {crypt} (because NIS can only grok that format).


> rob
>

Yeah that sounds like a possible fix, although a less than ideal one. Is it
possible to change it back to {SSHA} after all the clients have been
migrated suitably ? How would one force all the existing users' passwords
to be converted to {SSHA} once slapi-nis is no longer needed ?
-- 
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

[Guertin, David S.]

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

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] Active Directory Kerberos authentication on older versions of IPA clients

[Jakub Hrozek]

On Fri, Mar 27, 2015 at 05:00:43PM +, Srdjan Dutina wrote:
> Hi,
> 
> I created the following test environment:
> 
> 1. IPA server: v4.1.3 on Centos 7
> 2. Two-way trust with Active directory domain - Windows server 2012 R2
> 3. Connected multiple IPA clients:
> - Fedora 21 - v4.1.3
> - Centos 7 - v3.3.3
> - Centos 6.6 v.3.0.0
> 
> to IPA domain.
> 
> Using Kerberos ticket for AD user, I'm able to ssh to IPA server and Fedora
> client, but not to Centos clients, which have older IPA client versions.
> These clients just skip gssapi-with-mic auth and continue to password login
> (which is successful).
> 
> Just to add that I can obtain Kerberos ticket using 'kinit' command for AD
> user from all clients and also get user and group IDs using 'id' command.
> 
> Additionally, is it possible to join Centos 5 client to latest IPA server?
> 
> Thank you.

Sounds a bit like the auth_to_local rules might be acting up, did you
configure krb5.conf according to
http://www.freeipa.org/page/Active_Directory_trust_setup#Edit_.2Fetc.2Fkrb5.conf
?

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

[Freeipa-users] Active Directory Kerberos authentication on older versions of IPA clients

[Srdjan Dutina]

Hi,

I created the following test environment:

1. IPA server: v4.1.3 on Centos 7
2. Two-way trust with Active directory domain - Windows server 2012 R2
3. Connected multiple IPA clients:
- Fedora 21 - v4.1.3
- Centos 7 - v3.3.3
- Centos 6.6 v.3.0.0

to IPA domain.

Using Kerberos ticket for AD user, I'm able to ssh to IPA server and Fedora
client, but not to Centos clients, which have older IPA client versions.
These clients just skip gssapi-with-mic auth and continue to password login
(which is successful).

Just to add that I can obtain Kerberos ticket using 'kinit' command for AD
user from all clients and also get user and group IDs using 'id' command.

Additionally, is it possible to join Centos 5 client to latest IPA server?

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

Re: [Freeipa-users] subjectAlternitiveName for webservice

[Matt .]

I'm almost there but what happens when I regenerate a certificate for
the ldap server I get the following when I visit it through the
loadbalancer:

no alternative certificate subject name matches target host name
'ldap-01.domain'

I think this is strange as the certificate shows the ldap under the
altnames for HTTP/ldap-01 but there is indeed no ldap-01 as altname
but only on the certificate itself.



2015-03-26 16:48 GMT+01:00 Rob Crittenden :
> Matt . wrote:
>> HI Rob,
>>
>> Yes something is wrong there I guess.
>
> In any case, it doesn't apply to what you're trying to do.
>
>> But still, I actually need to add a SAN to the webserver cert, which
>> is different I think than the services at least.
>>
>> So the question there is... how ?
>
> What webserver cert? Are you trying to load balance the IPA services via
> DNS?
>
> Not knowing what you want, I'm just answering what you are ASKING. That
> is not the same as giving a proper answer. I have the feeling you want
> to load balance IPA in general which isn't going to work without a ton
> of (ongoing) manual effort. Even Microsoft recommends against trying
> this in its AD environment: http://support.microsoft.com/en-us/kb/325608
>
> In any case, the instructions I've already provided still apply.
>
> If you want to replace the Apache webserver cert you'll just need to do
> a couple of things first which has the potential of completely breaking
> IPA, so you'll need to be careful.
>
> Before you do anything, backup *.db in /etc/httpd/alias.
>
> Stop tracking the Apache cert in certmonger:
>
> # ipa-getcert stop-tracking -d /etc/httpd/alias -n Server-Cert
>
> Delete the existing cert:
>
> # certutil -D -d /etc/httpd/alias -n Server-Cert
>
> Like I said, destructive.
>
> Finally use certmonger to get a new cert that includes a SAN. The syntax
> is slightly different than before, mostly because I'm just guessing in
> the dark because you aren't including enough details into what you're
> trying.
>
> # ipa-getcert -d /etc/httpd/alias -n Server-Cert -N CN=ipa1.example.com
> -K HTTP/ipa1.example.com -D ipa.example.com -p /etc/httpd/alias/pwdfile.txt
>
> In this case the IPA server is ipa1.example.com and you're creating a
> SAN for ipa.example.com.
>
> Restart httpd.
>
> Note that this doesn't solve the Kerberos problem so cli access will
> still not work as expected. The UI _might_ work using forms-based
> authentication.
>
> I'd strongly urge you to think about the top of this e-mail before
> proceeding onto the bottom.
>
> rob
>
>>
>> Cheers,
>>
>> Matt
>>
>> 2015-03-26 14:50 GMT+01:00 Rob Crittenden :
>>> Matt . wrote:
 When digging around I see this documentation:

 http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/load-balancing.html

 I would except that server.example.com is not going to be accepted by
 IPA when you visit the webgui like that ?
>>>
>>> These are SRV records for the ldap service. Think of it as discovery for
>>> who provides ldap service in the domain. It isn't something used by a
>>> web browser.
>>>
>>> I'm no DNS expert (by far) but this example looks a little wonky. I'd
>>> think it should be example.com and not server.example.com. But in any
>>> case it is irrelevant to a browser.
>>>
>>> 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] passwordStorageScheme

[Sankar Ramlingam]

On 03/27/2015 06:21 PM, Andy Thompson wrote:

Relative newb here :) I'm doing some research trying to sort out the password 
storage scheme being used on the freeipa LDAP instance.  From everything I can 
find it uses ssha but can be changed to ssha-512.  But when I try to change 
that attribute on the cn=config object like referenced here 
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/User_Account_Management.html#Configuring_a_Global_Password_Policy_Using_the_Command_Line-Password_Policy_Attributes

It comes back with wrong attribute type.  I realize that doc points to the RHDS 
so it might be valid for the ipa ds?

Hi Andy,

The value has to be SHA512. Its not SHA-512.

/usr/bin/ldapmodify -x -p 1189 -h localhost -D "cn=Directory Manager" -w 
X << EOF

> dn: cn=config
> changetype: modify
> replace: passwordStorageScheme
> passwordStorageScheme: SHA-512
> EOF
modifying entry "cn=config"
ldap_modify: Operations error (1)
additional info: passwordStorageScheme: invalid scheme - SHA-512. 
Valid schemes are: CLEAR, CRYPT, MD5, SHA, SHA256, SHA384, SHA512, SMD5, 
SSHA, SSHA256, SSHA384, SSHA512


/usr/bin/ldapmodify -x -p 1189 -h localhost -D "cn=Directory Manager" -w 
X << EOF

dn: cn=config
changetype: modify
replace: passwordStorageScheme
passwordStorageScheme: SHA512
EOF

modifying entry "cn=config"


Hope this helps.

Thanks,
-Sankar R.


So I guess my question is what hash is used by freeipa to store password hashes 
and is it configurable?


*** This communication may contain privileged and/or confidential information. 
It is intended solely for the use of the addressee. If you are not the intended 
recipient, you are strictly prohibited from disclosing, copying, distributing 
or using any of this information. If you received this communication in error, 
please contact the sender immediately and destroy the material in its entirety, 
whether electronic or hard copy. ***




--
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] Fwd: Unexpected IPA Crashes

[Sankar Ramlingam]

On 03/27/2015 01:42 PM, David Kreuter wrote:
No, there are no entries with "segfaulter" neither in /var/log/messags 
nor in journalctr.


Meanwhile we encountered several directory server hangs and I was able 
to produce the stacktrace. Perhpas you can have a look.

Hi David,
You seem to have the latest/released version of 389-ds-base. You 
can probably try an upgrade to get the latest of other dependent 
components and 389-ds-base-debuginfo.


Thanks,
-Sankar R.




*From: *"David Kreuter" 
*To: *"freeipa-users" 
*Sent: *Thursday, 26 March, 2015 11:18:59 PM
*Subject: *Unexpected IPA Crashes

We have been using FreeIPA since two years and were more than happy. 
But since two weeks we are facing unexpected crashed and can not 
really debug the strange behaviours. The crashes are definitely not 
caused by connecting a new system or changing the LDAP schema heavily. 
Following IPA is used:


Name: ipa-server

Arch: x86_64

Version : 3.3.3

Release : 28.0.1.el7.centos.3

Size: 4.1 M


I have followed the troubleshooting 
guide http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#Troubleshooting 
and activated logging and activated the core dumping. Unfortunately, I 
cannot provide you any core dump, because it is not created after the 
ipa servers crashes. I'm sure the dirsrv is causing the problem, 
because when i restart the 389, then ipa works fine for a while. 
Currently I have activated the replication log level 8192. The error 
log shows no suspicious error or any fatal error. Following 389* 
versions are used:



Installed Packages

389-ds-base.x86_64 1.3.3.1-15.el7_1 
@/389-ds-base-1.3.3.1-15.el7_1.x86_64


389-ds-base-debuginfo.x86_64 1.3.1.6-26.el7_0 @base-debuginfo

389-ds-base-libs.x86_64 1.3.3.1-15.el7_1


Can you please provide some hint how I can debug this problem in more 
detail. Btw, the ipa infrastructure consist of one master and one 
replica. The server was also crashing, when the replica server was 
turned off. Do you thing an upgrade would solve the problem as the 
last resort?








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

[Guertin, David S.]

>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)
(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?

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] Understanding the migration mode

[Rob Crittenden]

Prasun Gera wrote:
> 
> The passwords will only show if they are in {crypt} format. If the
> password is changed in IPA it will use the default 389-ds password
> scheme which is a salted SHA.
> 
> 
> Yes, that's right. If the password is changed in IPA afterwards, it will
> stop working for NIS clients. This is the expected behaviour and that's
> fine. 
> 
>  
> 
> It may be, though I didn't think this was
> the case, that the password is being re-hashed during kerberos key
> generation.
> 
> 
> The kerberos keys for these users shouldn't be generated at all right ?
> So far I have been using the special webui page (/ipa/migration) to
> elevate old users to regular IPA users. The migration webui page needs
> the plaintext password in order to generate the kerberos keys. Until the
> migration step is complete, there are no kerberos keys. And that seems
> all right. i.e. Elevation to IPA users should happen only intentionally.

Keys can be generated in migration in two ways: by the migration web UI
or by sssd. I'm guessing you were unaware of this second method and that
is how the keys are being created.

> How long will you need to keep these legacy systems? This sharing of the
> password hashes is one of the (many) reasons people are migrating
> from NIS.
> 
>  
> These clients are actually not even that old. Most of them are on Ubuntu
> 12.04 or thereabouts. IPA client support on Ubuntu systems seems to be a
> bit buggy. I did manage to get it to work with ppas for ipa and sssd
> after some minor changes. This has improved in 14.04 from what I read,
> and it might be a better idea to bring the clients up to that before
> migrating. 

I'd suggest using nss_ldap over NIS. You can also manually configure
Kerberos and have basic functionality as long as nscld doesn't drive you
crazy.

AFAIK there is just one guy donating his time to create the ppas for
Debian for all the related IPA client and server packages, in his spare
time. I imagine he has to pick his battles carefully.

> 
> A fix may be to change the 389-ds password hashing scheme to crypt but
> that may just let these NIS systems linger forever. So it's the typical
> balance of usability vs security.
> 
> 
> I don't think the problem is the hashing scheme itself.  The old users'
> passwords were encrypted using MD5 and that's how I had imported them.
> Changing the scheme to something else after importing won't affect these
> passwords anyway right ? Or do you mean that if I change 389-ds's scheme
> to MD5 now, even if these users are elevated to IPA users, their hashes
> will continue to be visible from NIS clients. I thought the encryption
> scheme itself, and whether on not NIS clients see the encrypted password
> were two separate issues. 

It's not the encryption type, it is how it is encoded in 389-ds. When
you migrated the passwords they were stored as {crypt}hash. When the
password is changed in 389-ds it becomes {SSHA}hash. The NIS
configuration for slapi-nis only provides those passwords prefixed with
{crypt} (because NIS can only grok that format).

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

[Freeipa-users] config sudo with ipa

[Benoit Rousselle]

hi,

I setup a sudo config in client ipa and set rule in ipa server.
sudo rules from ipa are not found : it return 0 rules for the user

This config is ambiguous. Is there a method to check if everything is OK ?
The best way for this moment is to set debug_level on sssd. But I'm not
sure that the problem come from there.


(Fri Mar 27 14:12:36 2015) [sssd[sudo]] [ldb] (0x4000): Ending timer event
0x1cba830 "ltdb_callback"

(Fri Mar 27 14:12:36 2015) [sssd[sudo]] [sudosrv_get_sudorules_query_cache]
(0x0200): Searching sysdb with
[(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=my_user)(sudoUser=#161)(sudoUser=%utilisateur_a)(sudoUser=%adupont)(sudoUser=+*)))]
(Fri Mar 27 14:12:36 2015) [sssd[sudo]] [ldb] (0x4000): Added timed event
"ltdb_callback": 0x1cb9000

(Fri Mar 27 14:12:36 2015) [sssd[sudo]] [ldb] (0x4000): Added timed event
"ltdb_timeout": 0x1cb9240

(Fri Mar 27 14:12:36 2015) [sssd[sudo]] [ldb] (0x4000): Destroying timer
event 0x1cb9240 "ltdb_timeout"

(Fri Mar 27 14:12:36 2015) [sssd[sudo]] [ldb] (0x4000): Ending timer event
0x1cb9000 "ltdb_callback"

(Fri Mar 27 14:12:36 2015) [sssd[sudo]] [sudosrv_get_sudorules_from_cache]
(0x0400): Returning 0 rules for [my_user@my_domain.com]
(Fri Mar 27 14:12:36 2015) [sssd[sudo]] [reset_idle_timer] (0x4000): Idle
timer re-set for client [0x1cb30e0][18]


My client config :
[domain/my_domain.com]
debug_level = 6
cache_credentials = True
krb5_store_password_if_offline = True
krb5_realm = MY_IDMDOMAIN.COM
ipa_domain = my_domain.com
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = myserver.my_domain.com
chpass_provider = ipa
ipa_server = _srv_, idm.my_domain.com
ldap_tls_cacert = /etc/ipa/ca.crt
[sssd]
services = nss, pam, ssh, sudo
config_file_version = 2

domains = addcnet.com
[nss]

[pam]

[sudo]
debug_level = 9

[autofs]

[ssh]

[pac]


server redhat : LINUX 6.4
-- 
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] config sudo with ipa

[Lukas Slebodnik]

On (27/03/15 14:56), Benoit Rousselle wrote:
>hi,
>
>I setup a sudo config in client ipa and set rule in ipa server.
>sudo rules from ipa are not found : it return 0 rules for the user
>
>This config is ambiguous. Is there a method to check if everything is OK ?
>The best way for this moment is to set debug_level on sssd. But I'm not
>sure that the problem come from there.
>
>
>(Fri Mar 27 14:12:36 2015) [sssd[sudo]] [ldb] (0x4000): Ending timer event
>0x1cba830 "ltdb_callback"
>
>(Fri Mar 27 14:12:36 2015) [sssd[sudo]] [sudosrv_get_sudorules_query_cache]
>(0x0200): Searching sysdb with
>[(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=my_user)(sudoUser=#161)(sudoUser=%utilisateur_a)(sudoUser=%adupont)(sudoUser=+*)))]
>(Fri Mar 27 14:12:36 2015) [sssd[sudo]] [ldb] (0x4000): Added timed event
>"ltdb_callback": 0x1cb9000
>
>(Fri Mar 27 14:12:36 2015) [sssd[sudo]] [ldb] (0x4000): Added timed event
>"ltdb_timeout": 0x1cb9240
>
>(Fri Mar 27 14:12:36 2015) [sssd[sudo]] [ldb] (0x4000): Destroying timer
>event 0x1cb9240 "ltdb_timeout"
>
>(Fri Mar 27 14:12:36 2015) [sssd[sudo]] [ldb] (0x4000): Ending timer event
>0x1cb9000 "ltdb_callback"
>
>(Fri Mar 27 14:12:36 2015) [sssd[sudo]] [sudosrv_get_sudorules_from_cache]
>(0x0400): Returning 0 rules for [my_user@my_domain.com]
>(Fri Mar 27 14:12:36 2015) [sssd[sudo]] [reset_idle_timer] (0x4000): Idle
>timer re-set for client [0x1cb30e0][18]
>
>
>My client config :
>[domain/my_domain.com]
>debug_level = 6
>cache_credentials = True
>krb5_store_password_if_offline = True
>krb5_realm = MY_IDMDOMAIN.COM
>ipa_domain = my_domain.com
>id_provider = ipa
>auth_provider = ipa
>access_provider = ipa
>ipa_hostname = myserver.my_domain.com
>chpass_provider = ipa
>ipa_server = _srv_, idm.my_domain.com
>ldap_tls_cacert = /etc/ipa/ca.crt
>[sssd]
>services = nss, pam, ssh, sudo
>config_file_version = 2
>
>domains = addcnet.com
>[nss]
>
>[pam]
>
>[sudo]
>debug_level = 9
>
>[autofs]
>
>[ssh]
>
>[pac]
>
>
>server redhat : LINUX 6.4

rhel 6.4 has old version of sssd which does not have native ipa sudo provider.
You will need to configure sudo with sudo_provider = ldap.

Please follow instructions in manual page "sssd-sudo"

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

[Freeipa-users] passwordStorageScheme

[Andy Thompson]

Relative newb here :) I'm doing some research trying to sort out the password 
storage scheme being used on the freeipa LDAP instance.  From everything I can 
find it uses ssha but can be changed to ssha-512.  But when I try to change 
that attribute on the cn=config object like referenced here 
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/User_Account_Management.html#Configuring_a_Global_Password_Policy_Using_the_Command_Line-Password_Policy_Attributes

It comes back with wrong attribute type.  I realize that doc points to the RHDS 
so it might be valid for the ipa ds?

So I guess my question is what hash is used by freeipa to store password hashes 
and is it configurable?


*** This communication may contain privileged and/or confidential information. 
It is intended solely for the use of the addressee. If you are not the intended 
recipient, you are strictly prohibited from disclosing, copying, distributing 
or using any of this information. If you received this communication in error, 
please contact the sender immediately and destroy the material in its entirety, 
whether electronic or hard copy. ***


-- 
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] Unexpired pw?

[Martin Kosek]

On 03/27/2015 01:52 PM, Janelle wrote:
> 
> Hi all,
> 
> Found an odd issue and a question.  If you change user pw with "ipa user-mod 
> -password" and the client is configured for LDAP, then the user is not forced 
> to change the pw on initial login.

This is something we would like to fix eventually, it is tracked in
https://fedorahosted.org/freeipa/ticket/1539

It was not done yet as just forcing the password expiration on LDAP BIND tends
to break stuff.

-- 
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] Unexpired pw?

[Alexander Bokovoy]

On Fri, 27 Mar 2015, Janelle wrote:


Hi all,

Found an odd issue and a question.  If you change user pw with "ipa
user-mod -password" and the client is configured for LDAP, then the
user is not forced to change the pw on initial login.

We have three different cases depending on who changes userPassword
attribute in LDAP:

1. cn=Directory Manager can change anything and it doesn't taint the
userPassword.

2. A user can change own password and it doesn't taint the userPassword
attribute.

3. Any other identity that can change a password will taint userPassword
attribute.

If you change user password with "ipa user-mod --password" the question
should be "who are you?" and the answer to that question drives the
tainting logic described above.


However, my other question is, can you set a user pw WITHOUT
pre-expiring?!

cn=Directory manager is the one who can but directly in LDAP as you
cannot authenticate as 'cn=Directory manager' using IPA tools.

If you are insisting on lowering security of your passwords, nothing
prevents you from changing user password to some value as admin user
first and then setting it as that user to a correct value. We don't
recommend to do so but you have means already to ignore our
recommendations.

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

[Freeipa-users] Unexpired pw?

[Janelle]

Hi all,

Found an odd issue and a question.  If you change user pw with "ipa user-mod 
-password" and the client is configured for LDAP, then the user is not forced 
to change the pw on initial login.

However, my other question is, can you set a user pw WITHOUT pre-expiring?!

~J

-- 
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/IPA pw - not pre-expired

[Martin Kosek]

On 03/27/2015 06:23 AM, Janelle wrote:
> Hi again,
> 
> I can't seem to find it. Is there a way to create a new user with a 
> non-expired
> PW?

No clean way, by design. You can check our reasoning on this page:
https://www.freeipa.org/page/New_Passwords_Expired

There is a way (setting some DN as password synchronization agent), but this is
for PassSync mainly. Using it for regular admin user would be a hack and a bad
security practice.

HTH,
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] can't specify DNS name or subject in cert request in FreeIPA 3.3

[Martin Kosek]

You are doing it correctly. However, the DNS SubjectAltName only works with
FreeIPA 4.0+. The CA profile before this version does not allow them.

This is the upstream ticket:
https://fedorahosted.org/freeipa/ticket/3977

On 03/26/2015 07:09 PM, Steve Neuharth wrote:
> I'm trying to specify a subject name in a cert request like this:
> 
> ipa-getcert request -K HTTP/web.test.org -N *cn=www.test.org
> ,o=TEST.ORG * -f /tmp/webserver.crt
> -k /tmp/webprivate.key -r
> 
> or like this
> 
> ipa-getcert request -K HTTP/web.test.org -D www.test.org -f
> /tmp/webserver.crt -k /tmp/webprivate.key -r
> 
> The resulting certificate, however, just has the hostname of the server
> like this:
> 
> Request ID '20150326060555':
> status: MONITORING
> stuck: no
> key pair storage: type=FILE,location='/tmp/webprivate.key'
> certificate: type=FILE,location='/tmp/webserver.crt'
> CA: IPA
> issuer: CN=Certificate Authority,O=TEST.ORG
> subject: *CN=web.test.org ,O=TEST.ORG
> *
> expires: 2017-03-26 05:46:29 UTC
> key usage:
> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
> eku: id-kp-serverAuth,id-kp-clientAuth
> pre-save command:
> post-save command:
> track: yes
> auto-renew: yes
> 
> Is this a bug or am I doing something wrong in certmonger?
> 
> --steve
> 
> 
> 

-- 
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] Understanding the migration mode

[Prasun Gera]

>
>
> The passwords will only show if they are in {crypt} format. If the
> password is changed in IPA it will use the default 389-ds password
> scheme which is a salted SHA.


Yes, that's right. If the password is changed in IPA afterwards, it will
stop working for NIS clients. This is the expected behaviour and that's
fine.



> It may be, though I didn't think this was
> the case, that the password is being re-hashed during kerberos key
> generation.


The kerberos keys for these users shouldn't be generated at all right ? So
far I have been using the special webui page (/ipa/migration) to elevate
old users to regular IPA users. The migration webui page needs the
plaintext password in order to generate the kerberos keys. Until the
migration step is complete, there are no kerberos keys. And that seems all
right. i.e. Elevation to IPA users should happen only intentionally.


>
> How long will you need to keep these legacy systems? This sharing of the
> password hashes is one of the (many) reasons people are migrating from NIS.
>

These clients are actually not even that old. Most of them are on Ubuntu
12.04 or thereabouts. IPA client support on Ubuntu systems seems to be a
bit buggy. I did manage to get it to work with ppas for ipa and sssd after
some minor changes. This has improved in 14.04 from what I read, and it
might be a better idea to bring the clients up to that before migrating.


>
> A fix may be to change the 389-ds password hashing scheme to crypt but
> that may just let these NIS systems linger forever. So it's the typical
> balance of usability vs security.
>

I don't think the problem is the hashing scheme itself.  The old users'
passwords were encrypted using MD5 and that's how I had imported them.
Changing the scheme to something else after importing won't affect these
passwords anyway right ? Or do you mean that if I change 389-ds's scheme to
MD5 now, even if these users are elevated to IPA users, their hashes will
continue to be visible from NIS clients. I thought the encryption scheme
itself, and whether on not NIS clients see the encrypted password were two
separate issues.



>
> 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] bind-dyndb-ldap vs DLZ

[Petr Spacek]

On 27.3.2015 02:02, Jorgen Lundman wrote:
> Petr Spacek wrote:
>> Perfect! I can merge your changes upstream if you send me a patch with your
>> changes. It would make your life easier later when you need to pick new code.
> 
> Not a problem, I need to figure out why Solaris mkdir returns -1, with
> errno = 0. Goes against the manpage and all logic. Checking for ||errno==0
> after mkdir "fixes" it but it is still odd.

That is really weird! I'm bit worried that it would break something on some
other system so I'm not rushing to merge it upstream.

> I also compiled without krb5. It basically compiled, but running would fail
> to find gss/mech_krb5.so  - no idea how that is supposed to link, but since
> it was a quick test, I just took it out.

Interesting. I guess that the missing file is something like Kerberos module
for GSS-API library on Solaris.

Anyway, feel free to send fixes or a patch with --disable-kerberos option for
configure.

> Otherwise it compiled smoothly, some minor linux-ism with linker flags.

Could you be more specific, please? I can certainly fix linker flags if you
tell me how :-)

>> Hmm, that might be a challenge. bind-dyndb-ldap code implicitly assumes that
>> there is 1:1 mapping between DNS name<->LDAP DN. This makes implementation of
>> dynamic updates much easier.
> 
> Actually yes, I did mean to ask about this too. DLZ-LDAP is pretty much a
> read-only setup (for us), so a quick scan of the sources led me to believe
> that simple string replacement of "idnsName" with "DNSZoneName" (and of
> course, all the others), should get "a large chunk" of it done. The schemas
> are quite close, on a whole..

Yeah, changes for read-only mode could be pretty easy. See mainly
src/ldap_entry.c a src/ldap_convert.c.

> But I was surprised to see bind-dyndb actually modify the LDAP data, for my
> test, just "idnsSOAserial". What is the purpose of this? I would guess for
> zone xfers? By why update LDAP (and not just internal DNS memory), if you
> essentially do not use it on restart (just gets updated again on restart,
> from the looks of it?)

This is to make sure that SOA serial is incremented even if the server
crashed. The problem is that data in LDAP could be modified while server is
down so you have to increment SOA serial in all cases.

This could be optimized further when we finally have persistent copy of data
on disk, we could simply store syncrepl cookie somewhere and increment SOA
serial only if something was changed.

>>> the same delay each time I start it. slapd is running on localhost, and is
>>> otherwise idle. 
>>
>> Hmm, that stinks! I would be happy to look into it if you can provide me with
>> output from a profiler of your choice. (It might be a good idea to profile
>> bind-dyndb-ldap together with whole named process to see all the 
>> interactions.)
> 
> It is in line with what we experience with LDAP generally. If I blow away
> the DNS-ldap tree, a full syncrepl update takes about 1 hour. If I remove
> the whole LDAP tree, about 4 hours. It is not something that goes faster
> with more threads afaik.

Here I'm merging both you e-mails to one:

> Hold those horses. I must admit this timing didn't sit right with me, the
> more I thought about it. Since my test was all new, I created a slapd.conf
> from scratch. Forgot all about entryUUID index!

Interesting. Could you tell us how long it took to start-up with indexed
entryUUID but without the other changes?

Or more specifically, could you please measure impact of separate changes
mentioned below?

> I took out the creations of the empty master/$domain/keys directories. We
> don't use any of that.

This effectively breaks dynamic updates, IXFR and DNSSEC in-line signing but
it might not be a problem for you if you do not use these features.

> I noticed that its not the syncrepl that is slow, it is the MOD update of
> all idnsSOAserial.  Unfortunately, they are all on one connection, so
> increasing
> arg "connections 15";
> does not help.

Interesting. I believe that this is caused by internal event serialization in
bind-dyndb-ldap. All changes to idnsZone objects are processed only by single
thread (mainly purpose is AFAIK simplification of locking). It certainly can
be fixed and this fix should enable parallelization of zone loading.

BTW my guess is that you are testing the worst case - a lot of small zones. It
should scale better with bigger zones (but no guarantees here! :-).

> I took out the updates of idnsSOAserial by making
> ldap_replace_serial(return ISC_R_SUCCESS);
> 
> Startup time is just under 2 minutes. I can certainly live with that. Just
> go to work out if we can actually use it without idnsSOAserial or not. We

It has ~ no purpose if you do not do DNS zone transfers or in-line signing
(which depends on internal zone transfer).

> have just ldap master using syncrepl to each DNS server's local slapd. Then
> named to use that. No xfers, no slaves etc.

You probably do not need it.

> Shutdown 

Re: [Freeipa-users] Not able to SSH with User Created in IPA Server

[Natxo Asenjo]

On Fri, Mar 27, 2015 at 5:58 AM, Yogesh Sharma  wrote:

> (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [sss_krb5_cc_verify_ccache]
> (0x0020): 1078: [-1765328190][Credentials cache permissions incorrect]
> (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [check_old_ccache]
> (0x0040): Cannot check if saved ccache FILE:/tmp/krb5cc_131283_LTtoQU
> is valid
> (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [krb5_auth_send] (0x0020):
> check_if_ccache_file_is_used failed.
> (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [fo_resolve_service_send]
> (0x0100): Trying to resolve service 'IPA'
>

maybe this? Could you check what the permissions are on the kerberos cache
file for this test user?

-- 
regards,
Natxo
-- 
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] Not able to SSH with User Created in IPA Server

[Jakub Hrozek]

On Fri, Mar 27, 2015 at 12:34:57PM +0530, Yogesh Sharma wrote:
> No. This is the second attempt after changing the password on first login.
> 
> If you want I can re-send you the logs but this is the second login logs of
> this user.

Then it would be most interesting to see the logs of the password
change, I wonder if something went wrong there.

You said that if you change the password via kinit, then it's changed
successfully, right?

Does the wrong password change happen only on one certain host or do all
behave the same?

Did you configure the host using ipa-client-install or some manual
method? I just tested a new user with centos 7 server and git head
client and everything seemed to work fine..

-- 
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 Client Install on Amazon Linux

[Yogesh Sharma]

Gonzalo,

We have some running servers on Amazon Linux and it would be difficult to
migrate all those to CentOS or RHEL as of now. Hence If you can provide the
package's version then it would really help us till the time we do
migration.

For sure all over new Servers are going to be CentOS or RHEL.




*Best Regards,__*

*Yogesh Sharma*
*Email: yks0...@gmail.com  | Web: www.initd.in
*

RHCE, VCE-CIA, RackSpace Cloud U
[image: My LinkedIn Profile] 


On Fri, Mar 27, 2015 at 1:03 PM, Gonzalo Fernandez Ordas <
g.fer.or...@unicyber.co.uk> wrote:

>  Yogesh
>
> My personal experience using AWS Linux and LDAP is not a good one and
> mostly an utter nightmare in relation to packages.
> Personally I would recommend you to keep away from AWS Linux and get a
> Centos, Fedora or Redhat.
> Still, if you want to go ahead, I can give you the right versions for a
> couple of packages as the default sudo given by Amazon simply DOES NOT work
> (no idea what they have done to it..)
>
> Thanks
>
> On 27/03/2015 00:03, Yogesh Sharma wrote:
>
>  Hello,
>
>  Is there any repo available for Amazon Linux to install IPA Client OR
> below is the only way to do as found from freeipa-user mail archive.
>
>  http://www.redhat.com/archives/freeipa-users/2013-October/msg00058.html
>
>
>  Thanks for the help.
>
>
>
> * Best Regards, __ *
>
> *Yogesh Sharma *
>
>
>
>
>
-- 
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 Client Install on Amazon Linux

[Gonzalo Fernandez Ordas]

Yogesh

My personal experience using AWS Linux and LDAP is not a good one and 
mostly an utter nightmare in relation to packages.
Personally I would recommend you to keep away from AWS Linux and get a 
Centos, Fedora or Redhat.
Still, if you want to go ahead, I can give you the right versions for a 
couple of packages as the default sudo given by Amazon simply DOES NOT 
work (no idea what they have done to it..)


Thanks

On 27/03/2015 00:03, Yogesh Sharma wrote:

Hello,

Is there any repo available for Amazon Linux to install IPA Client OR 
below is the only way to do as found from freeipa-user mail archive.


http://www.redhat.com/archives/freeipa-users/2013-October/msg00058.html


Thanks for the help.
/
Best Regards,
__
/
/Yogesh Sharma
/





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

[Freeipa-users] IPA Client Install on Amazon Linux

[Yogesh Sharma]

Hello,

Is there any repo available for Amazon Linux to install IPA Client OR below
is the only way to do as found from freeipa-user mail archive.

http://www.redhat.com/archives/freeipa-users/2013-October/msg00058.html


Thanks for the help.



*Best Regards,__*

*Yogesh Sharma*
-- 
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] Not able to SSH with User Created in IPA Server

[Yogesh Sharma]

No. This is the second attempt after changing the password on first login.

If you want I can re-send you the logs but this is the second login logs of
this user.




*Best Regards,__*

*Yogesh Sharma*
*Email: yks0...@gmail.com  | Web: www.initd.in
*

RHCE, VCE-CIA, RackSpace Cloud U
[image: My LinkedIn Profile] 


On Fri, Mar 27, 2015 at 12:32 PM, Jakub Hrozek  wrote:

> On Fri, Mar 27, 2015 at 10:28:13AM +0530, Yogesh Sharma wrote:
> > Hi Jakub,
> >
> > Please find the logs for the user "test" created in IPA.
> >
> > (Fri Mar 27 10:19:52 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100):
> > Requesting info for [test] from []
> > (Fri Mar 27 10:19:52 2015) [sssd[nss]] [nss_cmd_getpwnam_search]
> (0x0100):
> > Requesting info for [t...@sd.int]
> > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [be_get_account_info]
> > (0x0100): Got request for [4097][1][name=test]
> > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]]
> > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse
> > domain SID from [(null)]
> > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [sdap_attrs_get_sid_str]
> > (0x0080): No [objectSIDString] attribute while id-mapping. [0][Success]
> > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]]
> > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse
> > domain SID from [(null)]
> > (Fri Mar 27 10:19:52 2015) [sssd[nss]] [nss_cmd_getpwnam_search]
> (0x0100):
> > Requesting info for [t...@sd.int]
> > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [acctinfo_callback]
> (0x0100):
> > Request processed. Returned 0,0,Success
> > (Fri Mar 27 10:19:52 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100):
> > Requesting info for [test] from []
> > (Fri Mar 27 10:19:52 2015) [sssd[nss]] [nss_cmd_initgroups_search]
> > (0x0100): Requesting info for [t...@sd.int]
> > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [be_get_account_info]
> > (0x0100): Got request for [4099][1][name=test]
> > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]]
> > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse
> > domain SID from [(null)]
> > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]]
> > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse
> > domain SID from [(null)]
> > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [sdap_attrs_get_sid_str]
> > (0x0080): No [objectSIDString] attribute while id-mapping. [0][Success]
> > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]]
> > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse
> > domain SID from [(null)]
> > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]]
> > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse
> > domain SID from [(null)]
> > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [sdap_attrs_get_sid_str]
> > (0x0080): No [objectSIDString] attribute while id-mapping. [0][Success]
> > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]]
> > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse
> > domain SID from [(null)]
> > (Fri Mar 27 10:19:52 2015) [sssd[nss]] [nss_cmd_initgroups_search]
> > (0x0100): Requesting info for [t...@sd.int]
> > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [acctinfo_callback]
> (0x0100):
> > Request processed. Returned 0,0,Success
> > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [be_get_account_info]
> > (0x0100): Got request for [1][1][name=test]
> > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]]
> > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse
> > domain SID from [(null)]
> > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [sdap_attrs_get_sid_str]
> > (0x0080): No [objectSIDString] attribute while id-mapping. [0][Success]
> > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]]
> > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse
> > domain SID from [(null)]
> > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [acctinfo_callback]
> (0x0100):
> > Request processed. Returned 0,0,Success
> > (Fri Mar 27 10:19:56 2015) [sssd] [service_send_ping] (0x0100): Pinging
> > sd.int
> > (Fri Mar 27 10:19:56 2015) [sssd] [service_send_ping] (0x0100): Pinging
> nss
> > (Fri Mar 27 10:19:56 2015) [sssd] [service_send_ping] (0x0100): Pinging
> pam
> > (Fri Mar 27 10:19:56 2015) [sssd] [service_send_ping] (0x0100): Pinging
> ssh
> > (Fri Mar 27 10:19:56 2015) [sssd] [service_send_ping] (0x0100): Pinging
> pac
> > (Fri Mar 27 10:19:56 2015) [sssd] [ping_check] (0x0100): Service pam
> > replied to ping
> > (Fri Mar 27 10:19:56 2015) [sssd] [ping_check] (0x0100): Service pac
> > replied to ping
> > (Fri Mar 27 10:19:56 2015) [sssd] [ping_check] (0x0100): Service ssh
> > replied to ping
> > (Fri Mar 27 10:19:56 2015) [sssd] [ping_check] (0x0100): Service nss
> > replied to ping
> > (Fri Mar 27 10:19:56 2015) [sssd] [ping_check] (0x0100): Service sd.int
> > replied to ping
> > (Fri Mar 27 10:19:57 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100):
> > 

Re: [Freeipa-users] Not able to SSH with User Created in IPA Server

[Jakub Hrozek]

On Fri, Mar 27, 2015 at 10:28:13AM +0530, Yogesh Sharma wrote:
> Hi Jakub,
> 
> Please find the logs for the user "test" created in IPA.
> 
> (Fri Mar 27 10:19:52 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100):
> Requesting info for [test] from []
> (Fri Mar 27 10:19:52 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100):
> Requesting info for [t...@sd.int]
> (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [be_get_account_info]
> (0x0100): Got request for [4097][1][name=test]
> (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]]
> [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse
> domain SID from [(null)]
> (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [sdap_attrs_get_sid_str]
> (0x0080): No [objectSIDString] attribute while id-mapping. [0][Success]
> (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]]
> [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse
> domain SID from [(null)]
> (Fri Mar 27 10:19:52 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100):
> Requesting info for [t...@sd.int]
> (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [acctinfo_callback] (0x0100):
> Request processed. Returned 0,0,Success
> (Fri Mar 27 10:19:52 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100):
> Requesting info for [test] from []
> (Fri Mar 27 10:19:52 2015) [sssd[nss]] [nss_cmd_initgroups_search]
> (0x0100): Requesting info for [t...@sd.int]
> (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [be_get_account_info]
> (0x0100): Got request for [4099][1][name=test]
> (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]]
> [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse
> domain SID from [(null)]
> (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]]
> [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse
> domain SID from [(null)]
> (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [sdap_attrs_get_sid_str]
> (0x0080): No [objectSIDString] attribute while id-mapping. [0][Success]
> (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]]
> [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse
> domain SID from [(null)]
> (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]]
> [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse
> domain SID from [(null)]
> (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [sdap_attrs_get_sid_str]
> (0x0080): No [objectSIDString] attribute while id-mapping. [0][Success]
> (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]]
> [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse
> domain SID from [(null)]
> (Fri Mar 27 10:19:52 2015) [sssd[nss]] [nss_cmd_initgroups_search]
> (0x0100): Requesting info for [t...@sd.int]
> (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [acctinfo_callback] (0x0100):
> Request processed. Returned 0,0,Success
> (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [be_get_account_info]
> (0x0100): Got request for [1][1][name=test]
> (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]]
> [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse
> domain SID from [(null)]
> (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [sdap_attrs_get_sid_str]
> (0x0080): No [objectSIDString] attribute while id-mapping. [0][Success]
> (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]]
> [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse
> domain SID from [(null)]
> (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [acctinfo_callback] (0x0100):
> Request processed. Returned 0,0,Success
> (Fri Mar 27 10:19:56 2015) [sssd] [service_send_ping] (0x0100): Pinging
> sd.int
> (Fri Mar 27 10:19:56 2015) [sssd] [service_send_ping] (0x0100): Pinging nss
> (Fri Mar 27 10:19:56 2015) [sssd] [service_send_ping] (0x0100): Pinging pam
> (Fri Mar 27 10:19:56 2015) [sssd] [service_send_ping] (0x0100): Pinging ssh
> (Fri Mar 27 10:19:56 2015) [sssd] [service_send_ping] (0x0100): Pinging pac
> (Fri Mar 27 10:19:56 2015) [sssd] [ping_check] (0x0100): Service pam
> replied to ping
> (Fri Mar 27 10:19:56 2015) [sssd] [ping_check] (0x0100): Service pac
> replied to ping
> (Fri Mar 27 10:19:56 2015) [sssd] [ping_check] (0x0100): Service ssh
> replied to ping
> (Fri Mar 27 10:19:56 2015) [sssd] [ping_check] (0x0100): Service nss
> replied to ping
> (Fri Mar 27 10:19:56 2015) [sssd] [ping_check] (0x0100): Service sd.int
> replied to ping
> (Fri Mar 27 10:19:57 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100):
> Requesting info for [test] from []
> (Fri Mar 27 10:19:57 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100):
> Requesting info for [t...@sd.int]
> (Fri Mar 27 10:19:57 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100):
> Requesting info for [test] from []
> (Fri Mar 27 10:19:57 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100):
> Requesting info for [t...@sd.int]
> (Fri Mar 27 10:19:57 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100):
> Requesting info for [test] from []
> (Fri Mar 27 10:19:57 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100):
> Requesting info for [t...@sd.int]
> (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_cmd_authenticat

Re: [Freeipa-users] bind-dyndb-ldap vs DLZ

[Jorgen Lundman]

> Hmm, that stinks! I would be happy to look into it if you can provide me with
> output from a profiler of your choice. (It might be a good idea to profile
> bind-dyndb-ldap together with whole named process to see all the 
> interactions.)
> 

Hold those horses. I must admit this timing didn't sit right with me, the
more I thought about it. Since my test was all new, I created a slapd.conf
from scratch. Forgot all about entryUUID index!

I took out the creations of the empty master/$domain/keys directories. We
don't use any of that.

I noticed that its not the syncrepl that is slow, it is the MOD update of
all idnsSOAserial.  Unfortunately, they are all on one connection, so
increasing
arg "connections 15";
does not help.

I took out the updates of idnsSOAserial by making
ldap_replace_serial(return ISC_R_SUCCESS);

Startup time is just under 2 minutes. I can certainly live with that. Just
go to work out if we can actually use it without idnsSOAserial or not. We
have just ldap master using syncrepl to each DNS server's local slapd. Then
named to use that. No xfers, no slaves etc.

Shutdown is still slow, but that appears to be a Solaris bug, after all
zones are shutdown and listening ports released, it sits around calling
lwp_park and unpark for 10 minutes. I can debug that later.



-- 
Jorgen Lundman   | 
Unix Administrator   | +81 (0)3 -5456-2687 ext 1017 (work)
Shibuya-ku, Tokyo| +81 (0)90-5578-8500  (cell)
Japan| +81 (0)3 -3375-1767  (home)

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