Re: [Freeipa-users] multiple ds instances (maybe off-topic)

[Alexander Bokovoy]

On Tue, 28 Jun 2016, Natxo Asenjo wrote:

hi,

according to the RHDS documentation (
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.1/html-single/Using_the_Admin_Server/index.html)
one can have multiple directory server instances on the same hosts

Would it be interesting to offer this functionality in freeipa.org? The
business case would be to allow different kinds of authentication per
instance/port. So one could block standard ldap connections on port 389 to
the internet, for instance, but allow them on another port only if using
external/GSSAPI auth, so no passswords would be involved.

This is not how instances work in 389-ds. Each instance is fully
independent of another one, including database content and structure.
You cannot have instance that shares the same content with another one
unless you enable database chaining (and then there are some
limitations).

We used to have CA instance separate from the main IPA instance, for
example, but then merged them together in the same instance using two
different backends.

Standard IPA 389-ds instance already allows its access on the unix domain
socket with EXTERNAL/GSSAPI authentication. It is visible only within
the scope of the IPA master host, of course.

I'm still not sure what exactly you would like to achieve. All ports
that 389-ds listens to do support the same authentication methods except
LDAPI protocol (unix domain sockets) which supports automapping between
POSIX ID and a user object that it maps to.


--
/ 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] multiple ds instances (maybe off-topic)

[Natxo Asenjo]

hi,

according to the RHDS documentation (
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.1/html-single/Using_the_Admin_Server/index.html)
one can have multiple directory server instances on the same hosts

Would it be interesting to offer this functionality in freeipa.org? The
business case would be to allow different kinds of authentication per
instance/port. So one could block standard ldap connections on port 389 to
the internet, for instance, but allow them on another port only if using
external/GSSAPI auth, so no passswords would be involved.

This would be useful for external services not using saml, for instance.

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

[Freeipa-users] How to give directory permissions on a specific client to FreeIPA users.

[Mitra Dehghan]

Hello,

I want to know how can I give directory permissions on a client to a domain
user in FreeIPA.


I'm using "runasuser" feature in sudo policy to give my domain users
permission to run local services on client.

Here is an example:
I have a service on my client called "*abc*" located at "/home/abc/" and
locally run by local user called "*abc*"

I have used runasuser feature in sudo policy rules to let domain users
(say: *u...@mydomain.dc*) run the service. *usr* can run scripts, read and
edit files and stop/start services, using *abc*'s permissions and without
any problem.

But the problem I have faced is, when I want "*usr*" to traverse
subdirectories under "*/home/abc/*" it doesn't work.
I have defined sudocmd for cd command and added it as allow-command to
appropriate sudorule. my sudocmd definitions are like this:


*ipa sudocmd-add --desc="ttt" 'cd /home/abc/n/'*

*ipa sudocmd-add --desc="ttt" 'cd /home/abc/m/'*
*ipa sudocmd-add --desc="ttt" 'cd /home/abc/n/q/'*

While *usr* can run the *cd* command without error, it doesn't work and
*pwd* still shows* /home/usr* as current directory.
what *usr* runs is:
*$ sudo -u abc cd /home/abc/m*/
-- 
respectfully
m-dehghan
-- 
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] multiple ds instances (maybe off-topic)

[Natxo Asenjo]

On Tue, Jun 28, 2016 at 9:07 AM, Alexander Bokovoy 
wrote:

> On Tue, 28 Jun 2016, Natxo Asenjo wrote:
>
>> hi,
>>
>> according to the RHDS documentation (
>>
>> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.1/html-single/Using_the_Admin_Server/index.html
>> )
>> one can have multiple directory server instances on the same hosts
>>
>> Would it be interesting to offer this functionality in freeipa.org? The
>> business case would be to allow different kinds of authentication per
>> instance/port. So one could block standard ldap connections on port 389 to
>> the internet, for instance, but allow them on another port only if using
>> external/GSSAPI auth, so no passswords would be involved.
>>
> This is not how instances work in 389-ds. Each instance is fully
> independent of another one, including database content and structure.
> You cannot have instance that shares the same content with another one
> unless you enable database chaining (and then there are some
> limitations).
>

ok, thanks for the info.


> We used to have CA instance separate from the main IPA instance, for
> example, but then merged them together in the same instance using two
> different backends.
>
> Standard IPA 389-ds instance already allows its access on the unix domain
> socket with EXTERNAL/GSSAPI authentication. It is visible only within
> the scope of the IPA master host, of course.
>
> I'm still not sure what exactly you would like to achieve. All ports
> that 389-ds listens to do support the same authentication methods except
> LDAPI protocol (unix domain sockets) which supports automapping between
> POSIX ID and a user object that it maps to.
>

I'd like to have internally all sort of ldap access, but externally onlly
certificate based, for example.

If there is a way to do that know that I am not aware of I'd be very
interested to know it as well ;-). Right now we solve this problems using
vpn connections with third parties, but ideally one could just open the
port to the internet if only that kind of access was allowed.


Thanks for your time.

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

[Freeipa-users] where is the CA cert located ?

[barrykfl]

Hi :

I already follow the procedure to install new CA and add ca.crt to the
library I known ...where still missed ?

 ABC-COM...[28/Jun/2016:15:45:53 +0800] - SSL alert:
CERT_VerifyCertificateNow: verify certificate failed for cert *.ABC.com of
family cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error
-8179 - Peer's Certificate issuer is not recognized.)


What files it relate to this ca.cert?


thks

Bar
-- 
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] multiple ds instances (maybe off-topic)

[Natxo Asenjo]

hi Ludwig,

On Tue, Jun 28, 2016 at 10:03 AM, Ludwig Krispenz 
wrote:

>
> On 06/28/2016 09:50 AM, Natxo Asenjo wrote:
>
>
> I'd like to have internally all sort of ldap access, but externally onlly
> certificate based, for example.
>
> If there is a way to do that know that I am not aware of I'd be very
> interested to know it as well ;-). Right now we solve this problems using
> vpn connections with third parties, but ideally one could just open the
> port to the internet if only that kind of access was allowed.
>
> maybe you can achieve this with access control, there are all kind of
> rules to allow access based on client's ip address, domain, security
> strength, authentication method - and combinations of them.
> 
>

Do you mean something like explained here:
http://directory.fedoraproject.org/docs/389ds/design/rootdn-access-control.html
?

Thanks!
--
Groeten,
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] multiple ds instances (maybe off-topic)

[Ludwig Krispenz]

On 06/28/2016 10:33 AM, Natxo Asenjo wrote:


hi Ludwig,

On Tue, Jun 28, 2016 at 10:03 AM, Ludwig Krispenz > wrote:



On 06/28/2016 09:50 AM, Natxo Asenjo wrote:


I'd like to have internally all sort of ldap access, but
externally onlly certificate based, for example.

If there is a way to do that know that I am not aware of I'd be
very interested to know it as well ;-). Right now we solve this
problems using vpn connections with third parties, but ideally
one could just open the port to the internet if only that kind of
access was allowed.

maybe you can achieve this with access control, there are all kind
of rules to allow access based on client's ip address, domain,
security strength, authentication method - and combinations of them.


Do you mean something like explained here: 
http://directory.fedoraproject.org/docs/389ds/design/rootdn-access-control.html 
?

I was thinking of something like this (and the other bind rules):

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Access_Control-Bind_Rules.html#Bind_Rules-Defining_Access_Based_on_Authentication_Method

the link you sent is about restraing access of directory manager, which 
is not subject to normal acis


Thanks!
--
Groeten,
natxo




--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander

-- 
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] multiple ds instances (maybe off-topic)

[Ludwig Krispenz]

On 06/28/2016 09:50 AM, Natxo Asenjo wrote:



On Tue, Jun 28, 2016 at 9:07 AM, Alexander Bokovoy 
> wrote:


On Tue, 28 Jun 2016, Natxo Asenjo wrote:

hi,

according to the RHDS documentation (

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.1/html-single/Using_the_Admin_Server/index.html)
one can have multiple directory server instances on the same hosts

Would it be interesting to offer this functionality in
freeipa.org ? The
business case would be to allow different kinds of
authentication per
instance/port. So one could block standard ldap connections on
port 389 to
the internet, for instance, but allow them on another port
only if using
external/GSSAPI auth, so no passswords would be involved.

This is not how instances work in 389-ds. Each instance is fully
independent of another one, including database content and structure.
You cannot have instance that shares the same content with another one
unless you enable database chaining (and then there are some
limitations).


ok, thanks for the info.

We used to have CA instance separate from the main IPA instance, for
example, but then merged them together in the same instance using two
different backends.

Standard IPA 389-ds instance already allows its access on the unix
domain
socket with EXTERNAL/GSSAPI authentication. It is visible only within
the scope of the IPA master host, of course.

I'm still not sure what exactly you would like to achieve. All ports
that 389-ds listens to do support the same authentication methods
except
LDAPI protocol (unix domain sockets) which supports automapping
between
POSIX ID and a user object that it maps to.


I'd like to have internally all sort of ldap access, but externally 
onlly certificate based, for example.


If there is a way to do that know that I am not aware of I'd be very 
interested to know it as well ;-). Right now we solve this problems 
using vpn connections with third parties, but ideally one could just 
open the port to the internet if only that kind of access was allowed.
maybe you can achieve this with access control, there are all kind of 
rules to allow access based on client's ip address, domain, security 
strength, authentication method - and combinations of them.



Thanks for your time.

--
regards,
Natxo





--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander

-- 
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 give directory permissions on a specific client to FreeIPA users.

[Mitra Dehghan]

Thank you Petr for your answer.  I'm trying to do the job with least
changes in client which was a operating machine now joined to Free IPA
domain.  I just want to make sure if using chmod,  chown or setfacl are the
only available solutions or not?
On Jun 28, 2016 12:30 PM, "Petr Spacek"  wrote:

> On 28.6.2016 09:08, Mitra Dehghan wrote:
> > Hello,
> >
> > I want to know how can I give directory permissions on a client to a
> domain
> > user in FreeIPA.
> >
> >
> > I'm using "runasuser" feature in sudo policy to give my domain users
> > permission to run local services on client.
> >
> > Here is an example:
> > I have a service on my client called "*abc*" located at "/home/abc/" and
> > locally run by local user called "*abc*"
> >
> > I have used runasuser feature in sudo policy rules to let domain users
> > (say: *u...@mydomain.dc*) run the service. *usr* can run scripts, read
> and
> > edit files and stop/start services, using *abc*'s permissions and without
> > any problem.
> >
> > But the problem I have faced is, when I want "*usr*" to traverse
> > subdirectories under "*/home/abc/*" it doesn't work.
> > I have defined sudocmd for cd command and added it as allow-command to
> > appropriate sudorule. my sudocmd definitions are like this:
> >
> >
> > *ipa sudocmd-add --desc="ttt" 'cd /home/abc/n/'*
> >
> > *ipa sudocmd-add --desc="ttt" 'cd /home/abc/m/'*
> > *ipa sudocmd-add --desc="ttt" 'cd /home/abc/n/q/'*
> >
> > While *usr* can run the *cd* command without error, it doesn't work and
> > *pwd* still shows* /home/usr* as current directory.
> > what *usr* runs is:
> > *$ sudo -u abc cd /home/abc/m*/
>
> Most importantly you need to add appropriate permission for user abc to the
> /home/abc directory (and its contents if necessary).
>
> You can use either chown+chmod or setfacl commands, depending on the
> use-case.
>
> When this is one, add SUDO rule allowing user usr to run a program in
> question. You do not need to bother with SUDO rules for "cd" because this
> will
> be solved at filesystem level.
>
> --
> Petr^2 Spacek
>
> --
> 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 give directory permissions on a specific client to FreeIPA users.

[Petr Spacek]

On 28.6.2016 12:32, Mitra Dehghan wrote:
> Thank you Petr for your answer.  I'm trying to do the job with least
> changes in client which was a operating machine now joined to Free IPA
> domain.  I just want to make sure if using chmod,  chown or setfacl are the
> only available solutions or not?

I believe that it is the only viable option because these checks are enforced
in filesystem layer in kernel.

Petr^2 Spacek


> On Jun 28, 2016 12:30 PM, "Petr Spacek"  wrote:
> 
>> On 28.6.2016 09:08, Mitra Dehghan wrote:
>>> Hello,
>>>
>>> I want to know how can I give directory permissions on a client to a
>> domain
>>> user in FreeIPA.
>>>
>>>
>>> I'm using "runasuser" feature in sudo policy to give my domain users
>>> permission to run local services on client.
>>>
>>> Here is an example:
>>> I have a service on my client called "*abc*" located at "/home/abc/" and
>>> locally run by local user called "*abc*"
>>>
>>> I have used runasuser feature in sudo policy rules to let domain users
>>> (say: *u...@mydomain.dc*) run the service. *usr* can run scripts, read
>> and
>>> edit files and stop/start services, using *abc*'s permissions and without
>>> any problem.
>>>
>>> But the problem I have faced is, when I want "*usr*" to traverse
>>> subdirectories under "*/home/abc/*" it doesn't work.
>>> I have defined sudocmd for cd command and added it as allow-command to
>>> appropriate sudorule. my sudocmd definitions are like this:
>>>
>>>
>>> *ipa sudocmd-add --desc="ttt" 'cd /home/abc/n/'*
>>>
>>> *ipa sudocmd-add --desc="ttt" 'cd /home/abc/m/'*
>>> *ipa sudocmd-add --desc="ttt" 'cd /home/abc/n/q/'*
>>>
>>> While *usr* can run the *cd* command without error, it doesn't work and
>>> *pwd* still shows* /home/usr* as current directory.
>>> what *usr* runs is:
>>> *$ sudo -u abc cd /home/abc/m*/
>>
>> Most importantly you need to add appropriate permission for user abc to the
>> /home/abc directory (and its contents if necessary).
>>
>> You can use either chown+chmod or setfacl commands, depending on the
>> use-case.
>>
>> When this is one, add SUDO rule allowing user usr to run a program in
>> question. You do not need to bother with SUDO rules for "cd" because this
>> will
>> be solved at filesystem level.

-- 
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 give directory permissions on a specific client to FreeIPA users.

[Christian Heimes]

On 2016-06-28 09:08, Mitra Dehghan wrote:
> 
> Hello,
> 
> I want to know how can I give directory permissions on a client to a
> domain user in FreeIPA.
> 
> 
> I'm using "runasuser" feature in sudo policy to give my domain users
> permission to run local services on client. 
> 
> Here is an example:
> I have a service on my client called "/abc/" located at "/home/abc/" and
> locally run by local user called "/abc/"
> 
> I have used runasuser feature in sudo policy rules to let domain users
> (say: /u...@mydomain.dc/) run the service. /usr/ can run scripts, read
> and edit files and stop/start services, using /abc/'s permissions and
> without any problem.
> 
> But the problem I have faced is, when I want "/usr/" to traverse
> subdirectories under "//home/abc//" it doesn't work.
> I have defined sudocmd for cd command and added it as allow-command to
> appropriate sudorule. my sudocmd definitions are like this:
> 
> /ipa sudocmd-add --desc="ttt" 'cd /home/abc/n/'
> /
> /ipa sudocmd-add --desc="ttt" 'cd /home/abc/m/'
> /
> /ipa sudocmd-add --desc="ttt" 'cd /home/abc/n/q/'/

cd is a builtin command of your shell. It has to be because it changes
the current working directory the shell's process. sudo doesn't work for
shell builtins. You have to find another way to accomplish your task.

By the way are you familiar how r,w,x work for directories? 'r' is used
for listing the content of a directory, 'w' for creating/removing files
(except for +t directories) and 'x' is used to check if a user is
allowed to enter a directory. You can allow users to enter a directory
w/o actually seeing its content.

Christian




signature.asc
Description: OpenPGP digital 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

Re: [Freeipa-users] IPA 3.0.47 to 3.0.50 Upgrade problem

[Sean Hogan]

Thanks Petr,

  Since the last recycle of the Host hosting the First Master it has been
stable for about a week now.  Only thing I did was to spread out my
replication agreements.  I had 8 replications hitting it but now have 4
going to it and the other 4 to its backup replica with the first master and
the backup replica having an agreement.


Not sure that fixed it or not but it seems to be stable at this point and I
know the docs say no more than 4 replications agreements so maybe it was
the cause.




Sean Hogan







From:   Petr Spacek 
To: Sean Hogan/Durham/IBM@IBMUS
Cc: freeipa-users@redhat.com
Date:   06/28/2016 10:24 AM
Subject:Re: [Freeipa-users] IPA 3.0.47 to 3.0.50 Upgrade problem



On 22.6.2016 23:09, Sean Hogan wrote:
> SLAPD showing
>
> 22/Jun/2016:17:01:59 -0400] slapi_ldap_bind - Error: could not perform
> interactive bind for id [] mech [GSSAPI]: error 49 (Invalid credentials)
> [22/Jun/2016:17:06:59 -0400] slapd_ldap_sasl_interactive_bind - Error:
> could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 49
> (Invalid credentials) (SASL(-13): authentication failure: GSSAPI Failure:
> gss_accept_sec_context) errno 0 (Success)
>
>
> where would these creds be and what ID?  I am using SASL so I assume it
to
> be sasl_user DNS/FirstMaster.watson.local  or something like that?

These are in /etc/dirsrv/ds.keytab.

I would start with
# klist -kt /etc/dirsrv/ds.keytab
and try to proceed with kinit etc. (very similarly to the bind-dyndb-ldap
how-to).

I hope it helps.

Petr^2 Spacek


> From:  Sean Hogan/Durham/IBM@IBMUS
> To:Petr Spacek 
> Cc:freeipa-users@redhat.com
> Date:  06/22/2016 08:36 AM
> Subject:   Re: [Freeipa-users] IPA 3.0.47 to 3.0.50 Upgrade 
> problem
> Sent by:   freeipa-users-boun...@redhat.com
>
>
>
> Hi Peter...
>
> Yes. this has me doing loops in my head to /dev/null
>
> You are correct I could not complete the BIND steps... I did them
yesterday
> but did not post results as I wanted to stop bugging you all :)
> The initial credential section of that I could not complete nor can I get
> an keytab without it and I don't think I have an issue with cert versions
> (used the SASL section). The upgrade log from 3.47 to 3.50 on this one
> server did show an error with named though.
>
> I had the box powered down again last night after testing the BIND
> procedures... and its been up since then. Which makes we really not sure
> what is going on(DNS DOS from internal maybe? I get a lot of outside
> requests showing network unreachable and I don't forward to a outside
DNS).
> If it was a password/cert/cipher/file perm issue then I don't see how it
> can work at all after a reboot.
>
> I am thinking it needs a rebuild.. I have not done this on a First Master
> IPA is there anything I need to be take into consider with it being first
> master? Right now I have 8 IPAs all DNS, NTP and CAs on differ vlans but
> the first master is the fail back IPA(on the only vlan that can talk to
the
> others) in case there local vlan IPA dies. First Master is also the
master
> CA in the realm where everything is enrolled to originally. We then mod
> everything to point to the vlan IPA with the Firstmaster as secondary
with
> our vlan-specific scripts we run after ipa client install.
>
> With the box rebooted last night I am now getting normal functionality
but
> it prob wont last long as indicated from the past...
>
> Working
> [bob@FirstMaster ~]# kinit admin
> Password for admin@DOMAIN.LOCAL:
> Warning: Your password will expire in 6 days on Tue Jun 28 14:55:52 2016
> [bob@FirstMaster ~]#
>
> I did post ldap logs in my first email though... will readd them to this
> and when it dies off again I will add more.
>
>
>> [20/Jun/2016:13:59:00 -0400] - Detected Disorderly Shutdown last time
>> Directory Server was running, recovering database.
>> [20/Jun/2016:13:59:01 -0400] schema-compat-plugin - warning: no entries
> set
>> up under cn=computers, cn=compat,dc=domain,dc=local
>> [20/Jun/2016:13:59:48 -0400] NSMMReplicationPlugin - ruv_compare_ruv:
RUV
>> [database RUV] does not contain element [{replica 7}
55ca26a90007
>> 5688d8e60017] which is present in RUV [changelog max RUV]
>> [20/Jun/2016:13:59:48 -0400] NSMMReplicationPlugin -
>> replica_check_for_data_reload: Warning: for replica dc=domain,dc=local
>> there were some differences between the changelog max RUV and the
> database
>> RUV. If there are obsolete elements in the database RUV, you should
> remove
>> them using the CLEANALLRUV task. If they are not obsolete, you should
> check
>> their status to see why there are no changes from those servers in the
>> changelog.
>> [20/Jun/2016:13:59:48 -0400] set_krb5_creds - Could not get initial
>> credentials for principal [ldap/server1.domain.local@DOMAIN.LOCAL] in
>> keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC
>> 

Re: [Freeipa-users] IPA 3.0.47 to 3.0.50 Upgrade problem

[Petr Spacek]

On 22.6.2016 23:09, Sean Hogan wrote:
> SLAPD showing
> 
> 22/Jun/2016:17:01:59 -0400] slapi_ldap_bind - Error: could not perform
> interactive bind for id [] mech [GSSAPI]: error 49 (Invalid credentials)
> [22/Jun/2016:17:06:59 -0400] slapd_ldap_sasl_interactive_bind - Error:
> could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 49
> (Invalid credentials) (SASL(-13): authentication failure: GSSAPI Failure:
> gss_accept_sec_context) errno 0 (Success)
> 
> 
> where would these creds be and what ID?  I am using SASL so I assume it to
> be sasl_user DNS/FirstMaster.watson.local  or something like that?

These are in /etc/dirsrv/ds.keytab.

I would start with
# klist -kt /etc/dirsrv/ds.keytab
and try to proceed with kinit etc. (very similarly to the bind-dyndb-ldap 
how-to).

I hope it helps.

Petr^2 Spacek


> From: Sean Hogan/Durham/IBM@IBMUS
> To:   Petr Spacek 
> Cc:   freeipa-users@redhat.com
> Date: 06/22/2016 08:36 AM
> Subject:  Re: [Freeipa-users] IPA 3.0.47 to 3.0.50 Upgrade problem
> Sent by:  freeipa-users-boun...@redhat.com
> 
> 
> 
> Hi Peter...
> 
> Yes. this has me doing loops in my head to /dev/null
> 
> You are correct I could not complete the BIND steps... I did them yesterday
> but did not post results as I wanted to stop bugging you all :)
> The initial credential section of that I could not complete nor can I get
> an keytab without it and I don't think I have an issue with cert versions
> (used the SASL section). The upgrade log from 3.47 to 3.50 on this one
> server did show an error with named though.
> 
> I had the box powered down again last night after testing the BIND
> procedures... and its been up since then. Which makes we really not sure
> what is going on(DNS DOS from internal maybe? I get a lot of outside
> requests showing network unreachable and I don't forward to a outside DNS).
> If it was a password/cert/cipher/file perm issue then I don't see how it
> can work at all after a reboot.
> 
> I am thinking it needs a rebuild.. I have not done this on a First Master
> IPA is there anything I need to be take into consider with it being first
> master? Right now I have 8 IPAs all DNS, NTP and CAs on differ vlans but
> the first master is the fail back IPA(on the only vlan that can talk to the
> others) in case there local vlan IPA dies. First Master is also the master
> CA in the realm where everything is enrolled to originally. We then mod
> everything to point to the vlan IPA with the Firstmaster as secondary with
> our vlan-specific scripts we run after ipa client install.
> 
> With the box rebooted last night I am now getting normal functionality but
> it prob wont last long as indicated from the past...
> 
> Working
> [bob@FirstMaster ~]# kinit admin
> Password for admin@DOMAIN.LOCAL:
> Warning: Your password will expire in 6 days on Tue Jun 28 14:55:52 2016
> [bob@FirstMaster ~]#
> 
> I did post ldap logs in my first email though... will readd them to this
> and when it dies off again I will add more.
> 
> 
>> [20/Jun/2016:13:59:00 -0400] - Detected Disorderly Shutdown last time
>> Directory Server was running, recovering database.
>> [20/Jun/2016:13:59:01 -0400] schema-compat-plugin - warning: no entries
> set
>> up under cn=computers, cn=compat,dc=domain,dc=local
>> [20/Jun/2016:13:59:48 -0400] NSMMReplicationPlugin - ruv_compare_ruv: RUV
>> [database RUV] does not contain element [{replica 7} 55ca26a90007
>> 5688d8e60017] which is present in RUV [changelog max RUV]
>> [20/Jun/2016:13:59:48 -0400] NSMMReplicationPlugin -
>> replica_check_for_data_reload: Warning: for replica dc=domain,dc=local
>> there were some differences between the changelog max RUV and the
> database
>> RUV. If there are obsolete elements in the database RUV, you should
> remove
>> them using the CLEANALLRUV task. If they are not obsolete, you should
> check
>> their status to see why there are no changes from those servers in the
>> changelog.
>> [20/Jun/2016:13:59:48 -0400] set_krb5_creds - Could not get initial
>> credentials for principal [ldap/server1.domain.local@DOMAIN.LOCAL] in
>> keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC
>> for requested realm)
>> [20/Jun/2016:13:59:48 -0400] set_krb5_creds - Could not get initial
>> credentials for principal [ldap/server1.domain.local@DOMAIN.LOCAL] in
>> keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC
>> for requested realm)
>> [20/Jun/2016:13:59:48 -0400] set_krb5_creds - Could not get initial
>> credentials for principal [ldap/server1.domain.local@DOMAIN.LOCAL] in
>> keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC
>> for requested realm)
>> [20/Jun/2016:13:59:48 -0400] 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 

[Freeipa-users] How to change the Kerberos Master Key?

[Nicholas Hinds]

Hi,

I have been trying to change the Kerberos Master Key of my FreeIPA
installation, without success.

On test installations, I have tried following the instructions on
http://web.mit.edu/kerberos/krb5-latest/doc/admin/database.html#updating-the-master-key,
but from the "kdb5_util update_princ_encryption" step onwards all kdb5_util
commands fail with "kdb5_util: No matching key in entry while looking up
active master key", and even "kdb5_util list_mkeys" fails to run after that
point.

I found https://fedorahosted.org/freeipa/ticket/4976 to document the
mechanism to change the Kerberos Master Key. It mentions that "Currently
the procedure is very hard and manual", but does not explain what the very
hard and manual way to change the key is.

Is it currently possible to change the Kerberos Master Key? If not, is it
okay to have a weak password set as the Kerberos Master Key if I secure
access to my FreeIPA server?


Thanks,
Nicholas.
-- 
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] Unable to add external group

[pgb205]

Trust is successfully established

ipa trust-find---1 trust matched---  Realm name:  
ad_domain.local  Domain NetBIOS name: AD_DOMAIN
and I can get kerberos ticket and access to servicesKRB5_TRACE=/dev/stderr kvno 
-S cifs ADDC.AD_DOMAIN
[3552] 1467143851.633980: Received creds for desired service 
cifs/ADDC.AD_DOMAIN[3552] 1467143851.634008: Storing my_user@AD_DOMAIN -> 
cifs/ADDC@AD_DOMAIN in 
KEYRING:persistent:0:krb_ccache_02UjQwjcifs/ADDC.AD_DOMAIN: kvno = 29
time is also correct and matches on both ipa and Domain Controller
When I go with the last few steps to add external AD group to the IPA 
--external I get the followingipa group-add-member ad_domain_admins_external 
--external 'AD_DOMAIN\Ops_Admins'[member user]:[member group]:  Group name: 
ad_domain_admins_external  Description: ad_domain_admins external map  Failed 
members:    member user:    member group: AD_DOMAIN\Ops_Admins: trusted domain 
object not found-Number of members added 0
I have verified the Ops_Admins is readable by everyone in Active Directory. 
In error_log I get
[:error] [pid 2619] ipa: INFO: [jsonserver_session] admin@IPA_DOMAIN: 
group_add_member(u'ad_domain_admins_external', 
ipaexternalmember=(u'AD_DOMAINOps_Admins',), all=False, raw=False, 
version=u'2.156', no_members=False): SUCCESS
Any idea on what steps I'm missing or what other things to check ?
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

Re: [Freeipa-users] Unable to add external group

[Alexander Bokovoy]

On Tue, 28 Jun 2016, pgb205 wrote:

Trust is successfully established

ipa trust-find---1 trust matched---  Realm name:  
ad_domain.local  Domain NetBIOS name: AD_DOMAIN
and I can get kerberos ticket and access to servicesKRB5_TRACE=/dev/stderr kvno 
-S cifs ADDC.AD_DOMAIN
[3552] 1467143851.633980: Received creds for desired service 
cifs/ADDC.AD_DOMAIN[3552] 1467143851.634008: Storing my_user@AD_DOMAIN -> 
cifs/ADDC@AD_DOMAIN in KEYRING:persistent:0:krb_ccache_02UjQwjcifs/ADDC.AD_DOMAIN: 
kvno = 29
time is also correct and matches on both ipa and Domain Controller
When I go with the last few steps to add external AD group to the IPA 
--external I get the followingipa group-add-member ad_domain_admins_external 
--external 'AD_DOMAIN\Ops_Admins'[member user]:[member group]:  Group name: 
ad_domain_admins_external  Description: ad_domain_admins external map  Failed 
members:    member user:    member group: AD_DOMAIN\Ops_Admins: trusted domain 
object not found-Number of members added 0
I have verified the Ops_Admins is readable by everyone in Active Directory. 
In error_log I get
[:error] [pid 2619] ipa: INFO: [jsonserver_session] admin@IPA_DOMAIN: 
group_add_member(u'ad_domain_admins_external', 
ipaexternalmember=(u'AD_DOMAINOps_Admins',), all=False, raw=False, 
version=u'2.156', no_members=False): SUCCESS
Any idea on what steps I'm missing or what other things to check ?

If you have "trusted domain object not found", this means you don't
really have trust established correctly. Unfortunately, sometimes we
cannot get proper error message back to the user as Samba Python
bindings don't give us much details.

See http://www.freeipa.org/page/Active_Directory_trust_setup#Debugging_trust on 
how to generate proper debug logs for trust to see what is there.

You kvno output is of no use -- obviously AD user would be able to
obtain a ticket to AD DC's service, this is not a surprise.
--
/ 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] freeIPA 4.2: Smart Card Issues

[Michael Rainey (Contractor)]

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.


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

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

Re: [Freeipa-users] Unable to add external group

[pgb205]

Alexander, forwarding sanitized files to you privately

  From: Alexander Bokovoy 
 To: pgb205  
Cc: "Freeipa-users@redhat.com" 
 Sent: Tuesday, June 28, 2016 4:25 PM
 Subject: Re: [Freeipa-users] Unable to add external group
   
On Tue, 28 Jun 2016, pgb205 wrote:
>Trust is successfully established
>
>ipa trust-find---1 trust matched---  Realm name:  
>ad_domain.local  Domain NetBIOS name: AD_DOMAIN
>and I can get kerberos ticket and access to servicesKRB5_TRACE=/dev/stderr 
>kvno -S cifs ADDC.AD_DOMAIN
>[3552] 1467143851.633980: Received creds for desired service 
>cifs/ADDC.AD_DOMAIN[3552] 1467143851.634008: Storing my_user@AD_DOMAIN -> 
>cifs/ADDC@AD_DOMAIN in 
>KEYRING:persistent:0:krb_ccache_02UjQwjcifs/ADDC.AD_DOMAIN: kvno = 29
>time is also correct and matches on both ipa and Domain Controller
>When I go with the last few steps to add external AD group to the IPA 
>--external I get the followingipa group-add-member ad_domain_admins_external 
>--external 'AD_DOMAIN\Ops_Admins'[member user]:[member group]:  Group name: 
>ad_domain_admins_external  Description: ad_domain_admins external map  Failed 
>members:    member user:    member group: AD_DOMAIN\Ops_Admins: trusted domain 
>object not found-Number of members added 0
>I have verified the Ops_Admins is readable by everyone in Active Directory. 
>In error_log I get
>[:error] [pid 2619] ipa: INFO: [jsonserver_session] admin@IPA_DOMAIN: 
>group_add_member(u'ad_domain_admins_external', 
>ipaexternalmember=(u'AD_DOMAINOps_Admins',), all=False, raw=False, 
>version=u'2.156', no_members=False): SUCCESS
>Any idea on what steps I'm missing or what other things to check ?
If you have "trusted domain object not found", this means you don't
really have trust established correctly. Unfortunately, sometimes we
cannot get proper error message back to the user as Samba Python
bindings don't give us much details.

See http://www.freeipa.org/page/Active_Directory_trust_setup#Debugging_trust on 
how to generate proper debug logs for trust to see what is there.

You kvno output is of no use -- obviously AD user would be able to
obtain a ticket to AD DC's service, this is not a surprise.
-- 
/ 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] How to reisnatll the ca or the dogtag system

[Barry]

Hi:

Errors occur ...cert ni problem ..seem ca error and cannot tract cert.
thx

ipa-replica-prepare c03.abc.com --ip-address 192.168.1.73
Directory Manager (existing master) password:

preparation of replica failed: cannot connect to
u'ldapi://%2fvar%2frun%2fslapd-WISERS-COM.socket': LDAP Server Down
cannot connect to u'ldapi://%2fvar%2frun%2fslapd-ABC.COM.socket': LDAP
Server Down
  File "/usr/sbin/ipa-replica-prepare", line 490, in 
main()

  File "/usr/sbin/ipa-replica-prepare", line 274, in main
conn.connect(bind_dn=DN(('cn', 'directory manager')),
bind_pw=dirman_password)

  File "/usr/lib/python2.6/site-packages/ipalib/backend.py", line 63, in
connect
conn = self.create_connection(*args, **kw)

  File "/usr/lib/python2.6/site-packages/ipaserver/plugins/ldap2.py", line
846, in create_connection
self.handle_errors(e)

  File "/usr/lib/python2.6/site-packages/ipaserver/plugins/ldap2.py", line
736, in handle_errors
error=u'LDAP Server Down')

[root@central ~]# ipa-replica-prepare central03.wisers.com --ip-address
192.168.1.73
Directory Manager (existing master) password:

preparation of replica failed: cannot connect to
u'ldapi://%2fvar%2frun%2fslapd-ABC.COM.socket': LDAP Server Down
cannot connect to u'ldapi://%2fvar%2frun%2fslapd-ABC-COM.socket': LDAP
Server Down
  File "/usr/sbin/ipa-replica-prepare", line 490, in 
main()

  File "/usr/sbin/ipa-replica-prepare", line 274, in main
conn.connect(bind_dn=DN(('cn', 'directory manager')),
bind_pw=dirman_password)

  File "/usr/lib/python2.6/site-packages/ipalib/backend.py", line 63, in
connect
conn = self.create_connection(*args, **kw)

  File "/usr/lib/python2.6/site-packages/ipaserver/plugins/ldap2.py", line
846, in create_connection
self.handle_errors(e)

  File "/usr/lib/python2.6/site-packages/ipaserver/plugins/ldap2.py", line
736, in handle_errors
error=u'LDAP Server Down')
-- 
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] disaster recovery

[Robert Story]

On Mon, 27 Jun 2016 08:59:14 -0400 Robert wrote:
RS> On Mon, 27 Jun 2016 08:09:59 +0200 Martin wrote:
RS> MB> On 26.06.2016 08:17, Robert Story wrote:  
RS> MB> > Hello,
RS> MB> >
RS> MB> > I was running a single ipa instance on Centos 7 for a small lab
RS> MB> > (ipa-server-4.2.0-15.0.1.el7.centos.17.x86_64), and the disk was 
corrupted.
RS> MB> > I have a (mostly) full backup (/var/log/ and /var/run/ excluded), 
which I
RS> MB> > restored. ipa server didn't start, and wanted me to run
RS> MB> > ipa-server-upgrade. This failed, and I see this in the log:
RS> MB> > [...]
RS> MB> Hello, upgrader refuses to upgrade because check which requires 
RS> MB> /var/lib/ipa  failed. Upgrader thinks that IPA is not installed.
RS> MB> 
RS> MB> So are you sure you have backup of /var/lib/ipa ?  
RS> 
RS> Yep, /var/lib/ipa is there:
RS> 
RS>  ls -lR
RS> [...]
RS> ./pki-ca/publish:
RS> total 0
RS> lrwxrwxrwx. 1 pkiuser pkiuser 57 Jun 24 21:00 MasterCRL.bin -> 
/var/lib/ipa/pki-ca/publish/MasterCRL-20160624-21.der
RS> 
RS> 
RS> Looking through the backups, I see that there are no MasterCRL files from
RS> the 25th (the backup I restored), but a bunch from the 24th, so maybe I
RS> need to try another restore with files from then...

So restoring /var/lib/ipa didn't work, and restoring the whole VM is taking
way to long. I have a new VM up with a new ipa-server install, and am
wondering if there is a way to import the data from the old filesystem?

Robert

-- 
Senior Software Engineer @ Parsons


pgpWdQ3DBFr2R.pgp
Description: OpenPGP digital 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