Re: [Freeipa-users] Failed to setup replica, slapi_ldap_bind fails

[Filip Pytloun]

Thank you, this information helped.
I have found related bugs:

FreeIPA: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786411
OpenLDAP switch to NSS:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725153
389ds ticket: https://fedorahosted.org/389/ticket/47536

It doesn't seem there's some functional workaround? :-/

On 2016/02/15 09:23, Rob Crittenden wrote:
> Filip Pytloun wrote:
> > I am using Ubuntu 16.04 (Xenial), there's no /etc/openldap
> 
> That's the problem right there. I don't believe Ubuntu supports setting
> up replication agreements yet due to gnutls vs NSS issues. An effort is
> being made upstream to eliminate the need for TLS during agreement setup
> but I don't believe the Ubuntu maintainer has had complete success in
> getting it working yet.
> 
> rob
> 
> > 
> > Here's complete debug log of replica install:
> > http://pastebin.com/38zi5MWd
> > 
> > Now I noticed following, don't know if it can directly relate to this issue:
> > 
> > ipa : DEBUGstderr=ldap_initialize( 
> > ldap://idm02.tcpcloud.eu:389/??base )
> > ldap_modify: Server is unwilling to perform (53)
> >  
> > ipa : CRITICAL Failed to load indices.ldif: Command 
> > ''/usr/bin/ldapmodify' '-v' '-f' '/usr/share/ipa/indices.ldif' '-H' 
> > 'ldap://idm02.tcpcloud.eu:389' '-x' '-D' 'cn=Directory Manager' '-y' 
> > '/tmp/tmpIV39iM'' returned non-zero exit status 53
> > 
> > On 2016/02/15 11:06, Ludwig Krispenz wrote:
> >>
> >> On 02/12/2016 06:22 PM, Filip Pytloun wrote:
> >>> Following is in /etc/ldap/ldap.conf on both servers (only URI differs):
> >> what is your OS, do you also have a /etc/openldap/ldap.conf
> >>
> >> ldapsearch and the replication connection shoudl use the same openldap
> >> libraries and so it is strange that -ZZ works and indside ds doesn't.
> >>
> >> At what point did your replica install fail, is there any hint in the
> >> replica install log ?
> >>>
> >>> TLS_CACERT /etc/ipa/ca.crt
> >>> TLS_REQCERT allow
> >>> URI ldaps://idm02.tcpcloud.eu
> >>> BASE dc=tcpcloud,dc=eu
> >>>
> >>> As ldapsearch is passing just fine on both nodes, I don't suppose
> >>> ldap.conf is wrong.
> >>> I also tried to set TLS_REQCERT to allow just to be sure (in case that
> >>> bad cert is provided).
> >>>
> >>> On 2016/02/12 16:57, Ludwig Krispenz wrote:
>  On 02/12/2016 03:35 PM, Filip Pytloun wrote:
> > It's the same as for idm01:
> >
> > [12/Feb/2016:15:24:26 +0100] NSMMReplicationPlugin - 
> > agmt="cn=meToidm01.tcpcloud.eu" (idm01:389): Replication bind with 
> > SIMPLE auth failed: LDAP error -11 (Connect error) ((unknown error 
> > code))
> > [12/Feb/2016:15:24:27 +0100] slapi_ldap_bind - Error: could not send 
> > startTLS request: error -11 (Connect error) errno 0 (Success)
>  you can get this connect error if the client side cannot verify the cert 
>  the
>  server sends, could you check what you have in f
> 
> > In access logs I can't read much interesting, just that TLS connection 
> > happened from idm01:
> >
> > [12/Feb/2016:15:33:11 +0100] conn=14 fd=64 slot=64 connection from 
> > 185.22.97.19 to 172.10.10.192
> > [12/Feb/2016:15:33:11 +0100] conn=14 op=0 EXT 
> > oid="1.3.6.1.4.1.1466.20037" name="startTLS"
> > [12/Feb/2016:15:33:11 +0100] conn=14 op=0 RESULT err=0 tag=120 
> > nentries=0 etime=0
> > [12/Feb/2016:15:33:11 +0100] conn=14 TLS1.2 128-bit AES-GCM
> > [12/Feb/2016:15:33:11 +0100] conn=14 op=-1 fd=64 closed - B1
> > [12/Feb/2016:15:33:59 +0100] conn=15 fd=64 slot=64 connection from 
> > 185.22.97.19 to 172.10.10.192
> > [12/Feb/2016:15:33:59 +0100] conn=15 op=0 EXT 
> > oid="1.3.6.1.4.1.1466.20037" name="startTLS"
> > [12/Feb/2016:15:33:59 +0100] conn=15 op=0 RESULT err=0 tag=120 
> > nentries=0 etime=0
> > [12/Feb/2016:15:34:00 +0100] conn=15 TLS1.2 128-bit AES-GCM
> > [12/Feb/2016:15:34:00 +0100] conn=15 op=-1 fd=64 closed - B1
> >
> > On 2016/02/12 15:22, Ludwig Krispenz wrote:
> >> On 02/12/2016 03:06 PM, Filip Pytloun wrote:
> >>> Hello,
> >>>
> >>> even when enabling replication logging, I get nothing useful in logs:
> >>>
> >>> [12/Feb/2016:14:57:00 +0100] NSMMReplicationPlugin - 
> >>> agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): Trying secure startTLS 
> >>> slapi_ldap_init_ext
> >>> [12/Feb/2016:14:57:00 +0100] NSMMReplicationPlugin - 
> >>> agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): binddn = cn=replication 
> >>> manager,cn=config,  passwd = {AES-some_encrypted_password
> >>> [12/Feb/2016:14:57:01 +0100] slapi_ldap_bind - Error: could not send 
> >>> startTLS request: error -11 (Connect error) errno 0 (Success)
> >>> [12/Feb/2016:14:57:01 +0100] NSMMReplicationPlugin - 
> >>> agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): Replication bind with 
> >>> SIMPLE auth failed: LDAP error -11 (Connect error) ((unknown error 
> >>> code))
> >>> [12/Feb/2016:14:57:01 

Re: [Freeipa-users] Question about ldap proxy/AD + sudo + HBAC

[Birnbaum, Warren (ETW)]

Jakub,

I am very interested in your standalone HBAC PAM module if you think it
would apply in this situation.  I would be happy to test it out if helpful.

Thanks again for you help,

Warren Birnbaum

___
Warren Birnbaum : Infrastructure Services
Digital Linux Infrastructure Services
Europe CDT Techn. Operations
Nike Inc. : Mobile +31 6 23902697






On 2/15/16, 5:16 PM, "Jakub Hrozek"  wrote:

>On Mon, Feb 15, 2016 at 03:58:15PM +, Birnbaum, Warren (ETW) wrote:
>> Jakub,
>> 
>> We want to use password stored in AD and get a yes/no from the AD side.
>
>OK, I see. Yes, with IPA provider you would authenticate the IPA user
>against the IPA KDC.
>
>> My understanding (which is very limited) is that if we use the IPA
>> authentication then it resides in the local kerberos database.  Is that
>> not correct?  If I am completely off, how would I setup type of
>> authentication from IPA up?
>
>Normally with trusts.
>
>> 
>> Thanks again,
>> 
>> Warren
>> ___
>> Warren Birnbaum : Infrastructure Services
>> Digital Linux Infrastructure Services
>> Europe CDT Techn. Operations
>> Nike Inc. : Mobile +31 6 23902697
>> 
>> 
>> 
>> 
>> 
>> 
>> On 2/15/16, 4:08 PM, "Jakub Hrozek"  wrote:
>> 
>> >On Mon, Feb 15, 2016 at 11:24:08AM +, Birnbaum, Warren (ETW) wrote:
>> >> Hi Jakub,
>> >> 
>> >> Thanks but I have sudo working OK.
>> >
>> >I'm sorry, my fault..
>> >
>> >> What I am trying make work is HBAC.
>> >> That I can¹t get to work with the proxy hack.  Is there a way to do
>> >>that?
>> >
>> >I haven't tested that use-case, but from the code it looks like it
>> >wouldn't work, because the HBAC code tries to match the originalDN of
>> >the user as stored on the IPA server.
>> >
>> >I'm finishing a standalone HBAC PAM module that could help in setups
>> >like this, but more importantly -- why do you have the user proxied
>>from
>> >files? Isn't it better to just rely on sssd's caching and fetch the
>>user
>> >from IPA?
>> 


-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Question about ldap proxy/AD + sudo + HBAC

[Birnbaum, Warren (ETW)]

Jakub,

We want to use password stored in AD and get a yes/no from the AD side.
My understanding (which is very limited) is that if we use the IPA
authentication then it resides in the local kerberos database.  Is that
not correct?  If I am completely off, how would I setup type of
authentication from IPA up?

Thanks again,

Warren
___
Warren Birnbaum : Infrastructure Services
Digital Linux Infrastructure Services
Europe CDT Techn. Operations
Nike Inc. : Mobile +31 6 23902697






On 2/15/16, 4:08 PM, "Jakub Hrozek"  wrote:

>On Mon, Feb 15, 2016 at 11:24:08AM +, Birnbaum, Warren (ETW) wrote:
>> Hi Jakub,
>> 
>> Thanks but I have sudo working OK.
>
>I'm sorry, my fault..
>
>> What I am trying make work is HBAC.
>> That I can¹t get to work with the proxy hack.  Is there a way to do
>>that?
>
>I haven't tested that use-case, but from the code it looks like it
>wouldn't work, because the HBAC code tries to match the originalDN of
>the user as stored on the IPA server.
>
>I'm finishing a standalone HBAC PAM module that could help in setups
>like this, but more importantly -- why do you have the user proxied from
>files? Isn't it better to just rely on sssd's caching and fetch the user
>from IPA?


-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] IPA inaccessable after adding service principle

[Martin Babinsky]

On 02/15/2016 04:41 PM, Sumit Bose wrote:

On Mon, Feb 15, 2016 at 04:27:15PM +0100, Martin Juhl wrote:

Hi guys

I've just installed a RHEL7 server with ipa-server 4.2.0...

Everything seems to work fine, until I add a service principle:

(Running on a client, after a kinit)

[root@dantooine ~]# ipa-getkeytab -s naboo.outerrim.lan -p 
HTTP/naboo.outerrim@outerrim.lan -k /etc/krb5.keytab
Keytab successfully retrieved and stored in: /etc/krb5.keytab


ipa-getkeytab will always create a new key unless you use the --retrieve
option.

It looks like you call ipa-getkeytab on the host dantooine, so it will
create a new key for naboo but save it on dantooine. So the keytab on
naboo will still have the old key but the KDC will hand out service
tickets with the new key which naboo does not know about.

Please try to call ipa-getkeytab with the --retrieve option on naboo so
that the new key is available on naboo as well.

HTH

bye,
Sumit




You will also need to regenerate apache keytab since by using the 
command you regenerate kerberos keys of HTTP service while leaving old 
keys in IPA HTTP service keytab, hence the decrypt integrity check error 
when using cli/webui.


on naboo.outerrim.lan, run:

"""
ipa-getkeytab -s naboo.outerrim.lan -p 
HTTP/naboo.outerrim@outerrim.lan -k /etc/httpd/conf/ipa.keytab

"""

and then either restart httpd service or run:

"""
kdestroy -c /var/run/httpd/ipa/krbcache/krb5ccache
"""

That should make webui and cli work again.





After running the command, the web-interface returns:

The password or username you entered is incorrect.

when I try to login, and the "ipa" command has stopped working as well (both on 
the server and client):


[root@dantooine ~]# ipa user-show admin
ipa: ERROR: Insufficient access: SASL(-1): generic failure: GSSAPI Error: 
Unspecified GSS failure.  Minor code may provide more information (KDC returned 
error string: 2ND_TKT_SERVER)
[root@dantooine ~]#
[root@dantooine ~]# kdestroy
[root@dantooine ~]# kinit admin
Password for ad...@outerrim.lan:
[root@dantooine ~]# ipa user-show admin
ipa: ERROR: cannot connect to 'https://naboo.outerrim.lan/ipa/json': 
Unauthorized


/var/log/httpd/error_log on the server gives me:

ValueError: non-generic 'CCacheError' needs format=None; got format="(-1765328353, 
'Decrypt integrity check failed')"


What did I do wrong here???

Regards

Martin Juhl

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





--
Martin^3 Babinsky

--
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] Question about ldap proxy/AD + sudo + HBAC

[Jakub Hrozek]

On Mon, Feb 15, 2016 at 03:58:15PM +, Birnbaum, Warren (ETW) wrote:
> Jakub,
> 
> We want to use password stored in AD and get a yes/no from the AD side.

OK, I see. Yes, with IPA provider you would authenticate the IPA user
against the IPA KDC.

> My understanding (which is very limited) is that if we use the IPA
> authentication then it resides in the local kerberos database.  Is that
> not correct?  If I am completely off, how would I setup type of
> authentication from IPA up?

Normally with trusts.

> 
> Thanks again,
> 
> Warren
> ___
> Warren Birnbaum : Infrastructure Services
> Digital Linux Infrastructure Services
> Europe CDT Techn. Operations
> Nike Inc. : Mobile +31 6 23902697
> 
> 
> 
> 
> 
> 
> On 2/15/16, 4:08 PM, "Jakub Hrozek"  wrote:
> 
> >On Mon, Feb 15, 2016 at 11:24:08AM +, Birnbaum, Warren (ETW) wrote:
> >> Hi Jakub,
> >> 
> >> Thanks but I have sudo working OK.
> >
> >I'm sorry, my fault..
> >
> >> What I am trying make work is HBAC.
> >> That I can¹t get to work with the proxy hack.  Is there a way to do
> >>that?
> >
> >I haven't tested that use-case, but from the code it looks like it
> >wouldn't work, because the HBAC code tries to match the originalDN of
> >the user as stored on the IPA server.
> >
> >I'm finishing a standalone HBAC PAM module that could help in setups
> >like this, but more importantly -- why do you have the user proxied from
> >files? Isn't it better to just rely on sssd's caching and fetch the user
> >from IPA?
> 

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Disable IPA Web UI auto-login

[Petr Vobornik]

Hello,

On 02/15/2016 02:12 PM, Wanderley Mayhé wrote:



Hello Rob



Regarding the thread
https://www.redhat.com/archives/freeipa-users/2010-July/msg00022.html I
have tested to set KrbMethodK5Passwd to “on” and restarted httpd but IPA
Web UI was still trying to auto-login user through a browser dialog.



In order to effectively disable this browser dialog, I had to edit
/etc/httpd/conf.d/ipa.conf

and add this line set KrbMethodNegotiate to off as follows (and restarted
httpd):





# Protect /ipa and everything below it in webspace with Apache Kerberos
auth



   AuthType Kerberos

   AuthName "Kerberos Login"

##  KrbMethodNegotiate on

KrbMethodNegotiate off

   KrbMethodK5Passwd off

   KrbServiceName HTTP

   KrbAuthRealms IBP.ORG.BR

   Krb5KeyTab /etc/httpd/conf/ipa.keytab

   KrbSaveCredentials on

   KrbConstrainedDelegation on

   Require valid-user

   ErrorDocument 401 /ipa/errors/unauthorized.html





Am I correct to assume that that JSON API will not be affected by this
change?


No



Is there any major problems this setting could cause?



Yes, it would affect the API :)

Better option would be to modify Web UI with UI plugin to skip Kerberous 
auth - harder to explain.


Or easier thing might be to modify ipa.conf in a way that 
/ipa/session/login_kerberos would not return negotiate headers but would 
fail immediately with 401.


--
Petr Vobornik

--
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] Connection closed by UNKNOWN

[Jakub Hrozek]

On Mon, Feb 15, 2016 at 06:59:57PM +0530, Rakesh Rajasekharan wrote:
> this is what I have in /var/log/secure
> 
> Feb 15 12:22:33 ipa-xyz sshd[13499]: pam_unix(sshd:auth): authentication
> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x  user=tempuser
> Feb 15 12:22:33 ipa-xyz sshd[13499]: pam_sss(sshd:auth): authentication
> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x user=tempuser
> Feb 15 12:22:33 ipa-xyz sshd[13499]: pam_sss(sshd:auth): received for user
> tempuser: 7 (Authentication failure)
> Feb 15 12:22:33 ipa-xyz sshd[13499]: pam_ldap: ldap_simple_bind Can't
> contact LDAP server
> Feb 15 12:22:33 ipa-xyz sshd[13499]: pam_ldap: reconnecting to LDAP
> server...
> Feb 15 12:22:33 ipa-xyz sshd[13499]: pam_ldap: ldap_simple_bind Can't
> contact LDAP server

Why is both pam_ldap and pam_sss in the PAM stack? This seems a bit
wrong..

> Feb 15 12:22:35 ipa-xyz sshd[13499]: Failed password for tempuser from
> x.x.x.x port 34318 ssh2
> Feb 15 12:22:37 ipa-xyz sshd[13500]: Connection closed by x.x.x.x
> Feb 15 12:31:32 ipa-xyz sshd[13859]: Accepted publickey for root from
> x.x.x.x port 56275 ssh2
> Feb 15 12:31:32 ipa-xyz sshd[13859]: pam_unix(sshd:session): session opened
> for user root by (uid=0)
> Feb 15 13:01:32 ipa-xyz sshd[13859]: Received disconnect from x.x.x.x: 11:
> disconnected by user
> 
> but both 389 and 636 ports are listening
> # ] netstat -tunlp |grep 636
> tcp0  0 :::636  :::*
> LISTEN  9564/ns-slapd
> 
> #] netstat -tunlp |grep 389
> tcp0  0 :::7389 :::*
> LISTEN  9495/ns-slapd
> tcp0  0 :::389  :::*
> LISTEN  9564/ns-slapd
> 
> 
> And from /var/log/sssd/sssd_xyz.com.log
> 
> (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100):
> command: PAM_AUTHENTICATE
> (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100):
> domain: xyz.com
> (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100):
> user: tempuser
> (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100):
> service: sshd
> (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100):
> tty: ssh
> (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100):
> ruser:
> (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100):
> rhost: x.x.x.x
> (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100):
> authtok type: 1
> (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100):
> newauthtok type: 0
> (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100):
> priv: 1
> (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100):
> cli_pid: 13499
> (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100):
> logon name: not set
> (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]]
> [krb5_auth_prepare_ccache_name] (0x1000): No ccache file for user
> [tempuser] found.
> (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [fo_resolve_service_send]
> (0x0100): Trying to resolve service 'IPA'
> (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [get_server_status]
> (0x1000): Status of server 'ipa.xyz.com' is 'working'
> (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [get_port_status] (0x1000):
> Port status of port 0 for server 'ipa.xyz.com' is 'working'
> (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [get_server_status]
> (0x1000): Status of server 'ipa.xyz.com' is 'working'
> (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [be_resolve_server_process]
> (0x1000): Saving the first resolved server
> (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [be_resolve_server_process]
> (0x0200): Found address for server ipa.xyz.com: [x.x.x.x] TTL 7200
> (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [write_pipe_handler]
> (0x0400): All data has been sent!
> (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [child_sig_handler]
> (0x1000): Waiting for child [13501].
> (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [child_sig_handler]
> (0x0100): child [13501] finished successfully.
> (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [read_pipe_handler]
> (0x0400): EOF received, client finished
> (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [be_pam_handler_callback]
> (0x0100): Backend returned: (0, 7, ) [Success]

I think you need to look into krb5_child.log with a high debug_level.

> (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [be_pam_handler_callback]
> (0x0100): Sending result [7][xyz.com]
> (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [be_pam_handler_callback]
> (0x0100): Sent result [7][xyz.com]
> 
> 
> 
> Thanks,
> Rakesh
> 
> 
> On Mon, Feb 15, 2016 at 3:45 PM, Jakub Hrozek  wrote:
> 
> > On Mon, Feb 15, 2016 at 10:24:23AM +0530, Rakesh Rajasekharan wrote:
> > > hbac seems to be fine
> > >
> > >
> > > ipa hbactest --user=q-temp --host=x.x.x.x --service=sshd
> > > 
> > > Access granted: True
> 

Re: [Freeipa-users] IPA inaccessable after adding service principle

[Sumit Bose]

On Mon, Feb 15, 2016 at 04:27:15PM +0100, Martin Juhl wrote:
> Hi guys
> 
> I've just installed a RHEL7 server with ipa-server 4.2.0...
> 
> Everything seems to work fine, until I add a service principle:
> 
> (Running on a client, after a kinit)
> 
> [root@dantooine ~]# ipa-getkeytab -s naboo.outerrim.lan -p 
> HTTP/naboo.outerrim@outerrim.lan -k /etc/krb5.keytab
> Keytab successfully retrieved and stored in: /etc/krb5.keytab

ipa-getkeytab will always create a new key unless you use the --retrieve
option.

It looks like you call ipa-getkeytab on the host dantooine, so it will
create a new key for naboo but save it on dantooine. So the keytab on
naboo will still have the old key but the KDC will hand out service
tickets with the new key which naboo does not know about.

Please try to call ipa-getkeytab with the --retrieve option on naboo so
that the new key is available on naboo as well.

HTH

bye,
Sumit


> 
> 
> After running the command, the web-interface returns:
> 
> The password or username you entered is incorrect.
> 
> when I try to login, and the "ipa" command has stopped working as well (both 
> on the server and client):
> 
> 
> [root@dantooine ~]# ipa user-show admin
> ipa: ERROR: Insufficient access: SASL(-1): generic failure: GSSAPI Error: 
> Unspecified GSS failure.  Minor code may provide more information (KDC 
> returned error string: 2ND_TKT_SERVER)
> [root@dantooine ~]# 
> [root@dantooine ~]# kdestroy
> [root@dantooine ~]# kinit admin
> Password for ad...@outerrim.lan: 
> [root@dantooine ~]# ipa user-show admin
> ipa: ERROR: cannot connect to 'https://naboo.outerrim.lan/ipa/json': 
> Unauthorized
> 
> 
> /var/log/httpd/error_log on the server gives me:
> 
> ValueError: non-generic 'CCacheError' needs format=None; got 
> format="(-1765328353, 'Decrypt integrity check failed')"
> 
> 
> What did I do wrong here???
> 
> Regards
> 
> Martin Juhl
> 
> -- 
> 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

[Freeipa-users] IPA inaccessable after adding service principle

[Martin Juhl]

Hi guys

I've just installed a RHEL7 server with ipa-server 4.2.0...

Everything seems to work fine, until I add a service principle:

(Running on a client, after a kinit)

[root@dantooine ~]# ipa-getkeytab -s naboo.outerrim.lan -p 
HTTP/naboo.outerrim@outerrim.lan -k /etc/krb5.keytab
Keytab successfully retrieved and stored in: /etc/krb5.keytab


After running the command, the web-interface returns:

The password or username you entered is incorrect.

when I try to login, and the "ipa" command has stopped working as well (both on 
the server and client):


[root@dantooine ~]# ipa user-show admin
ipa: ERROR: Insufficient access: SASL(-1): generic failure: GSSAPI Error: 
Unspecified GSS failure.  Minor code may provide more information (KDC returned 
error string: 2ND_TKT_SERVER)
[root@dantooine ~]# 
[root@dantooine ~]# kdestroy
[root@dantooine ~]# kinit admin
Password for ad...@outerrim.lan: 
[root@dantooine ~]# ipa user-show admin
ipa: ERROR: cannot connect to 'https://naboo.outerrim.lan/ipa/json': 
Unauthorized


/var/log/httpd/error_log on the server gives me:

ValueError: non-generic 'CCacheError' needs format=None; got 
format="(-1765328353, 'Decrypt integrity check failed')"


What did I do wrong here???

Regards

Martin Juhl

-- 
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] Question about ldap proxy/AD + sudo + HBAC

[Jakub Hrozek]

On Mon, Feb 15, 2016 at 11:24:08AM +, Birnbaum, Warren (ETW) wrote:
> Hi Jakub,
> 
> Thanks but I have sudo working OK. 

I'm sorry, my fault..

> What I am trying make work is HBAC.
> That I can¹t get to work with the proxy hack.  Is there a way to do that?

I haven't tested that use-case, but from the code it looks like it
wouldn't work, because the HBAC code tries to match the originalDN of
the user as stored on the IPA server.

I'm finishing a standalone HBAC PAM module that could help in setups
like this, but more importantly -- why do you have the user proxied from
files? Isn't it better to just rely on sssd's caching and fetch the user
from IPA?

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Failed to setup replica, slapi_ldap_bind fails

[Rob Crittenden]

Filip Pytloun wrote:
> I am using Ubuntu 16.04 (Xenial), there's no /etc/openldap

That's the problem right there. I don't believe Ubuntu supports setting
up replication agreements yet due to gnutls vs NSS issues. An effort is
being made upstream to eliminate the need for TLS during agreement setup
but I don't believe the Ubuntu maintainer has had complete success in
getting it working yet.

rob

> 
> Here's complete debug log of replica install:
> http://pastebin.com/38zi5MWd
> 
> Now I noticed following, don't know if it can directly relate to this issue:
> 
> ipa : DEBUGstderr=ldap_initialize( 
> ldap://idm02.tcpcloud.eu:389/??base )
> ldap_modify: Server is unwilling to perform (53)
>  
> ipa : CRITICAL Failed to load indices.ldif: Command 
> ''/usr/bin/ldapmodify' '-v' '-f' '/usr/share/ipa/indices.ldif' '-H' 
> 'ldap://idm02.tcpcloud.eu:389' '-x' '-D' 'cn=Directory Manager' '-y' 
> '/tmp/tmpIV39iM'' returned non-zero exit status 53
> 
> On 2016/02/15 11:06, Ludwig Krispenz wrote:
>>
>> On 02/12/2016 06:22 PM, Filip Pytloun wrote:
>>> Following is in /etc/ldap/ldap.conf on both servers (only URI differs):
>> what is your OS, do you also have a /etc/openldap/ldap.conf
>>
>> ldapsearch and the replication connection shoudl use the same openldap
>> libraries and so it is strange that -ZZ works and indside ds doesn't.
>>
>> At what point did your replica install fail, is there any hint in the
>> replica install log ?
>>>
>>> TLS_CACERT /etc/ipa/ca.crt
>>> TLS_REQCERT allow
>>> URI ldaps://idm02.tcpcloud.eu
>>> BASE dc=tcpcloud,dc=eu
>>>
>>> As ldapsearch is passing just fine on both nodes, I don't suppose
>>> ldap.conf is wrong.
>>> I also tried to set TLS_REQCERT to allow just to be sure (in case that
>>> bad cert is provided).
>>>
>>> On 2016/02/12 16:57, Ludwig Krispenz wrote:
 On 02/12/2016 03:35 PM, Filip Pytloun wrote:
> It's the same as for idm01:
>
> [12/Feb/2016:15:24:26 +0100] NSMMReplicationPlugin - 
> agmt="cn=meToidm01.tcpcloud.eu" (idm01:389): Replication bind with SIMPLE 
> auth failed: LDAP error -11 (Connect error) ((unknown error code))
> [12/Feb/2016:15:24:27 +0100] slapi_ldap_bind - Error: could not send 
> startTLS request: error -11 (Connect error) errno 0 (Success)
 you can get this connect error if the client side cannot verify the cert 
 the
 server sends, could you check what you have in f

> In access logs I can't read much interesting, just that TLS connection 
> happened from idm01:
>
> [12/Feb/2016:15:33:11 +0100] conn=14 fd=64 slot=64 connection from 
> 185.22.97.19 to 172.10.10.192
> [12/Feb/2016:15:33:11 +0100] conn=14 op=0 EXT 
> oid="1.3.6.1.4.1.1466.20037" name="startTLS"
> [12/Feb/2016:15:33:11 +0100] conn=14 op=0 RESULT err=0 tag=120 nentries=0 
> etime=0
> [12/Feb/2016:15:33:11 +0100] conn=14 TLS1.2 128-bit AES-GCM
> [12/Feb/2016:15:33:11 +0100] conn=14 op=-1 fd=64 closed - B1
> [12/Feb/2016:15:33:59 +0100] conn=15 fd=64 slot=64 connection from 
> 185.22.97.19 to 172.10.10.192
> [12/Feb/2016:15:33:59 +0100] conn=15 op=0 EXT 
> oid="1.3.6.1.4.1.1466.20037" name="startTLS"
> [12/Feb/2016:15:33:59 +0100] conn=15 op=0 RESULT err=0 tag=120 nentries=0 
> etime=0
> [12/Feb/2016:15:34:00 +0100] conn=15 TLS1.2 128-bit AES-GCM
> [12/Feb/2016:15:34:00 +0100] conn=15 op=-1 fd=64 closed - B1
>
> On 2016/02/12 15:22, Ludwig Krispenz wrote:
>> On 02/12/2016 03:06 PM, Filip Pytloun wrote:
>>> Hello,
>>>
>>> even when enabling replication logging, I get nothing useful in logs:
>>>
>>> [12/Feb/2016:14:57:00 +0100] NSMMReplicationPlugin - 
>>> agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): Trying secure startTLS 
>>> slapi_ldap_init_ext
>>> [12/Feb/2016:14:57:00 +0100] NSMMReplicationPlugin - 
>>> agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): binddn = cn=replication 
>>> manager,cn=config,  passwd = {AES-some_encrypted_password
>>> [12/Feb/2016:14:57:01 +0100] slapi_ldap_bind - Error: could not send 
>>> startTLS request: error -11 (Connect error) errno 0 (Success)
>>> [12/Feb/2016:14:57:01 +0100] NSMMReplicationPlugin - 
>>> agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): Replication bind with 
>>> SIMPLE auth failed: LDAP error -11 (Connect error) ((unknown error 
>>> code))
>>> [12/Feb/2016:14:57:01 +0100] NSMMReplicationPlugin - 
>>> agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): Disconnected from the 
>>> consumer
>> what is in the access and error logs of idm02 for this time ?
>>> But I can bind just fine manually:
>>>
>>> ldapsearch -D "cn=replication manager,cn=config" -w some_password -b 
>>> cn=config -h idm02 -ZZ
>>>
>>> I am starting to be clueless, nobody has an idea what could be wrong?
>>>
>>> - DNS including PTR records are set up fine
>>> - /etc/hosts is setup fine
>>> - conncheck passes fine between nodes

[Freeipa-users] SOLUTION to Failed replica install with /32 netmask

[Aaron Estrada]

I tried creating a FreeIPA replica in GCE.

GCE is a little weird in that it's DHCP assigns a /32 netmask to VMs. There
does not seem to be any way to disable that specific behavior in GCE since
as a user you have no control of the DHCP server. As a user you can create
your own networks but it seems that under the hood Google wants to always
route everything themselves, so even though they allow you to create say a
/16 network, the machines all get a /32 netmask and use the gateway for
routing, even within their own network. It's actually a little confusing
because from the view of the the machine, you actually have no way of
determining the size of the network (you have to actually learn the
netmask/size of the virtual network via other means, like the glcoud
command or web console)

But with the /32 netmask routing does work, and machines can find other
machines. Unfortunately, the FreeIPA server install scripts seem to have
some error checking that gets confused by the /32 netmask scheme GCE uses
and causes the scripts to crap out.

I managed to trick ipa-server-install into installing by temporarily
manually opening up the netmask. It only kind of works, since in some cases
it breaks networking and the connection to the machine is lost. However,
once IPA server is set up, it keeps working and I can enroll client
machines.  It seems like too much of a hack and I couldn't get he same
trick to work for replicas in any case. This is the error I get:

File
"/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py",
line 877, in main install_check(self) File
"/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py",
line 295, in decorated func(installer) File
"/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py",
line 514, in install_check options.ip_addresses) File
"/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line
516, in get_server_ip_address
sys.exit(1)ipa.ipapython.install.cli.install_tool(Replica): DEBUG The
ipa-replica-install command failed, exception: SystemExit: 1

I went into installutils.py and commented out the error test at line 516:

# if not ips:
# print >> sys.stderr, "No usable IP address provided nor resolved."
# sys.exit(1)

It's an ugly hack but you can at least get past the error check and install
the replica.

Would it be possible to make the installer scripts a less sensitive to the
/32 netmask?
-- 
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] client/authentication inside a docker container

[Jan Pazdziora]

On Thu, Feb 04, 2016 at 12:37:07PM -0500, Prasun Gera wrote:
> On Thu, Feb 4, 2016 at 10:56 AM, Jan Pazdziora 
> wrote:
> 
> > > The goal is to run the
> > > docker container such that when the user calls docker run,
> >
> > Is any user allowed to run docker run? That seems like a security
> > issue.
> 
> Well any user that can do sudo should be able to run docker. Is there a
> security issue with that ?

You need to limit those sudo calls to very specific list of
parameters that can be passed to the docker client, otherwise it has
the potential of running any command.

> > > it just drops
> > > into a shell with the container's environment, but everything else looks
> > > largely the same. i.e. The user gets the same uid:gid and sees the same
> > > directories and permissions as the host.
> >
> > So you want bash started in the container, with the uid:gid of the
> > person invoking the command? If the users are trusted to do docker
> > run, they can do
> >
> > docker run -u $UID container bash
> >
> > themselves.
> 
> Yes, this is similar to the 3rd point I mentioned. The problem though is
> that directory listings will not show names inside the container. They'll

In that case, having sssd-client package installed in the container and
/var/lib/sss mounted to the container could help.

> only show uids and gids. NIS solves this as a quick hack, but is there
> something better ? Permissions would still work since NFS is not
> kerberized. Another issue I haven't figured out is how the user can get
> sudo inside the container. If you start docker with the user's uid, I don't
> know if there is a safe way for that user to get sudo inside. If you start
> docker in the root shell, you can create the user with the uid:gid, add it
> to sudoers, and then change to the user's shell ?

Yes.

If you have /var/lib/sss mounted and sssd-common (or libsss_sudo
in new versions) installed in the container, you can even use the
sudo rules from IPA.

> > But you likely do not want to give every user a way to run any command,
> > why not just use sudo, and
> >
> > docker run -u $SUDO_UID container bash
> >
> > in the script invoked with the sudo (untested)?
> 
> I didn't follow this. Can you explain a bit more ? In the default setup,
> you anyway need sudo to run docker.

Not really -- access to docker's Unix socket is all that the docker
client needs.

> What is the -u string here ?

Setting the uid under which the container processes are run back to
the invoking user.

-- 
Jan Pazdziora
Senior Principal Software Engineer, Identity Management Engineering, Red Hat

-- 
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] Connection closed by UNKNOWN

[Rakesh Rajasekharan]

this is what I have in /var/log/secure

Feb 15 12:22:33 ipa-xyz sshd[13499]: pam_unix(sshd:auth): authentication
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x  user=tempuser
Feb 15 12:22:33 ipa-xyz sshd[13499]: pam_sss(sshd:auth): authentication
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x user=tempuser
Feb 15 12:22:33 ipa-xyz sshd[13499]: pam_sss(sshd:auth): received for user
tempuser: 7 (Authentication failure)
Feb 15 12:22:33 ipa-xyz sshd[13499]: pam_ldap: ldap_simple_bind Can't
contact LDAP server
Feb 15 12:22:33 ipa-xyz sshd[13499]: pam_ldap: reconnecting to LDAP
server...
Feb 15 12:22:33 ipa-xyz sshd[13499]: pam_ldap: ldap_simple_bind Can't
contact LDAP server
Feb 15 12:22:35 ipa-xyz sshd[13499]: Failed password for tempuser from
x.x.x.x port 34318 ssh2
Feb 15 12:22:37 ipa-xyz sshd[13500]: Connection closed by x.x.x.x
Feb 15 12:31:32 ipa-xyz sshd[13859]: Accepted publickey for root from
x.x.x.x port 56275 ssh2
Feb 15 12:31:32 ipa-xyz sshd[13859]: pam_unix(sshd:session): session opened
for user root by (uid=0)
Feb 15 13:01:32 ipa-xyz sshd[13859]: Received disconnect from x.x.x.x: 11:
disconnected by user

but both 389 and 636 ports are listening
# ] netstat -tunlp |grep 636
tcp0  0 :::636  :::*
LISTEN  9564/ns-slapd

#] netstat -tunlp |grep 389
tcp0  0 :::7389 :::*
LISTEN  9495/ns-slapd
tcp0  0 :::389  :::*
LISTEN  9564/ns-slapd


And from /var/log/sssd/sssd_xyz.com.log

(Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100):
command: PAM_AUTHENTICATE
(Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100):
domain: xyz.com
(Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100):
user: tempuser
(Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100):
service: sshd
(Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100):
tty: ssh
(Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100):
ruser:
(Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100):
rhost: x.x.x.x
(Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100):
authtok type: 1
(Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100):
newauthtok type: 0
(Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100):
priv: 1
(Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100):
cli_pid: 13499
(Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100):
logon name: not set
(Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]]
[krb5_auth_prepare_ccache_name] (0x1000): No ccache file for user
[tempuser] found.
(Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [fo_resolve_service_send]
(0x0100): Trying to resolve service 'IPA'
(Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [get_server_status]
(0x1000): Status of server 'ipa.xyz.com' is 'working'
(Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [get_port_status] (0x1000):
Port status of port 0 for server 'ipa.xyz.com' is 'working'
(Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [get_server_status]
(0x1000): Status of server 'ipa.xyz.com' is 'working'
(Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [be_resolve_server_process]
(0x1000): Saving the first resolved server
(Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [be_resolve_server_process]
(0x0200): Found address for server ipa.xyz.com: [x.x.x.x] TTL 7200
(Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [write_pipe_handler]
(0x0400): All data has been sent!
(Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [child_sig_handler]
(0x1000): Waiting for child [13501].
(Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [child_sig_handler]
(0x0100): child [13501] finished successfully.
(Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [read_pipe_handler]
(0x0400): EOF received, client finished
(Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [be_pam_handler_callback]
(0x0100): Backend returned: (0, 7, ) [Success]
(Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [be_pam_handler_callback]
(0x0100): Sending result [7][xyz.com]
(Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [be_pam_handler_callback]
(0x0100): Sent result [7][xyz.com]



Thanks,
Rakesh


On Mon, Feb 15, 2016 at 3:45 PM, Jakub Hrozek  wrote:

> On Mon, Feb 15, 2016 at 10:24:23AM +0530, Rakesh Rajasekharan wrote:
> > hbac seems to be fine
> >
> >
> > ipa hbactest --user=q-temp --host=x.x.x.x --service=sshd
> > 
> > Access granted: True
> > 
> >   Matched rules: allow_all
> >
> >
> > I see this in the sssd.log
> >
> > (Mon Feb 15 04:49:18 2016) [sssd[nss]] [sss_ncache_check_str] (0x2000):
> > Checking negative cache for [NCE/USER/xyz.com/q-temp]
> > (Mon Feb 15 04:49:18 2016) [sssd[nss]] [nss_cmd_getpwnam_search]
> (0x0100):
> > Requesting info for [q-t...@xyz.com]
> > (Mon Feb 15 04:49:18 2016) [sssd[nss]] [check_cache] (0x0400): Cached
> 

[Freeipa-users] Disable IPA Web UI auto-login

[Wanderley Mayhé]

Hello Rob



Regarding the thread
https://www.redhat.com/archives/freeipa-users/2010-July/msg00022.html I
have tested to set KrbMethodK5Passwd to “on” and restarted httpd but IPA
Web UI was still trying to auto-login user through a browser dialog.



In order to effectively disable this browser dialog, I had to edit
/etc/httpd/conf.d/ipa.conf

and add this line set KrbMethodNegotiate to off as follows (and restarted
httpd):





# Protect /ipa and everything below it in webspace with Apache Kerberos
auth



  AuthType Kerberos

  AuthName "Kerberos Login"

##  KrbMethodNegotiate on

KrbMethodNegotiate off

  KrbMethodK5Passwd off

  KrbServiceName HTTP

  KrbAuthRealms IBP.ORG.BR

  Krb5KeyTab /etc/httpd/conf/ipa.keytab

  KrbSaveCredentials on

  KrbConstrainedDelegation on

  Require valid-user

  ErrorDocument 401 /ipa/errors/unauthorized.html





Am I correct to assume that that JSON API will not be affected by this
change?

Is there any major problems this setting could cause?



Att

Wanderley









-- 
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 reference to IPA Server in Multi-Master Setup ?

[Petr Spacek]

On 26.1.2016 13:18, Zeal Vora wrote:
> Thanks David.
> 
> Generally for Operating systems like Amazon Linux etc which does not have a
> IPA-Client, we generally use SSSD to get things working.
> 
> In such cases, what would be optimal way to configure the SRV records as
> --domain parameter won't be present.

Hi,

ipa-client just configures SSSD, so SRV records will work just fine if you
configure it by hand.

Anyway, I would recommend you either to push Amazon to include IPA support in
their distro or to use RHEL/CentOS in AWS.

Petr^2 Spacek

> On Mon, Jan 25, 2016 at 5:16 PM, David Kupka  wrote:
> 
>> On 25/01/16 12:08, Zeal Vora wrote:
>>
>>> Thanks Petr.
>>>
>>> So if the domain is example.com, in DNS, what would be the IP associated
>>> with it ?
>>>
>>> As there are 2 master servers, each of them will have different IP
>>> address.
>>>
>>> On Mon, Jan 25, 2016 at 4:34 PM, Petr Spacek  wrote:
>>>
>>> On 25.1.2016 10:47, Zeal Vora wrote:

> Hi
>
> I have setup a multi-master IPA and it seems to be working fine.
>
> The clients ( laptops and servers ) are not using the DNS of IPA.
>
> I was wondering, while configuring ipa-client, which server do I
>
 reference

> to when it asks the ipa-server hostname ?
>
> Both the master server has different hostnames.
>
> master1.example.com  ( Master 1 )
> master2.example.com  ( Master 2 )
>

 Specify only --domain option and do not use --server option at all. In
 will
 enable server auto-detection using DNS SRV records and you will not need
 to
 worry about adding/removing servers because all clients will
 automatically
 pick the new list up.

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


>>>
>>>
>>>
>> The '--domain' parameter is for client installer to form DNS request.
>> Request that is sent is the same as one sent by this command:
>> dig -t SRV _ldap._tcp.
>>
>> It then receiver list of records similar to this one:
>> 100 0 389 
>> 100 0 389 
>>
>> Installer then goes through the list and checks if it's really FreeIPA
>> server and first one that passes is used. When IP address is needed it can
>> be resolved from the name included in SRV response.
>>
>> HTH,
>> --
>> David Kupka
>>
> 


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

Re: [Freeipa-users] Question about ldap proxy/AD + sudo + HBAC

[Alexander Bokovoy]

On Mon, 15 Feb 2016, Birnbaum, Warren (ETW) wrote:

Alexander,

Thanks for letting me know this.  Is it true then that my only option is
to have the IPA AD trust to achieve AD authentication (proxy style), HBAC
and sudo?

I'm not sure using 'proxy' term is actually helpful here. IPA does not
work as a proxy authentication when it trusts AD forest. All
authentication happens directly against AD domain controllers, and IPA
is only used to host resources specific to Linux deployments. Given that
HBAC is a feature of IPA, not AD, you cannot have HBAC working in other
configurations.

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

Re: [Freeipa-users] Question about ldap proxy/AD + sudo + HBAC

[Lukas Slebodnik]

On (15/02/16 11:45), Birnbaum, Warren (ETW) wrote:
>Thanks Lukas.  
>
>Unfortunately setting up a IPA Ad Trust is something not possible within
>our organization.  Is it then fair to say that waiting for Ticket #4623 is
>our only option?  https://fedorahosted.org/freeipa/ticket/4634
>

As I wrote in previous mail HBAC can work only with id_provider = ipa.
and GPO works only with id_provider = ad.

Your configuration is little bit non-standard
id_provider = proxy (to files) and auth provider LDAP (AD).

I can only recommend to look into pam_access.so.

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

Re: [Freeipa-users] Question about ldap proxy/AD + sudo + HBAC

[Birnbaum, Warren (ETW)]

Alexander,

Thanks for letting me know this.  Is it true then that my only option is
to have the IPA AD trust to achieve AD authentication (proxy style), HBAC
and sudo?

Thanks
___
Warren Birnbaum : Infrastructure Services
Digital Linux Infrastructure Services
Europe CDT Techn. Operations
Nike Inc. : Mobile +31 6 23902697






On 2/15/16, 12:52 PM, "Alexander Bokovoy"  wrote:

>On Mon, 15 Feb 2016, Birnbaum, Warren (ETW) wrote:
>>Thanks Lukas.
>>
>>Unfortunately setting up a IPA Ad Trust is something not possible within
>>our organization.  Is it then fair to say that waiting for Ticket #4623
>>is
>>our only option?  https://fedorahosted.org/freeipa/ticket/4634
>This ticket is not going to be implemented in a near future. It has
>huge development cost while very little benefits. I don't think it is
>going to be something you can rely on.
>
>-- 
>/ 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

Re: [Freeipa-users] Question about ldap proxy/AD + sudo + HBAC

[Alexander Bokovoy]

On Mon, 15 Feb 2016, Birnbaum, Warren (ETW) wrote:

Thanks Lukas.

Unfortunately setting up a IPA Ad Trust is something not possible within
our organization.  Is it then fair to say that waiting for Ticket #4623 is
our only option?  https://fedorahosted.org/freeipa/ticket/4634

This ticket is not going to be implemented in a near future. It has
huge development cost while very little benefits. I don't think it is
going to be something you can rely on.

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

Re: [Freeipa-users] Question about ldap proxy/AD + sudo + HBAC

[Birnbaum, Warren (ETW)]

Thanks Lukas.  

Unfortunately setting up a IPA Ad Trust is something not possible within
our organization.  Is it then fair to say that waiting for Ticket #4623 is
our only option?  https://fedorahosted.org/freeipa/ticket/4634


Thanks,

Warren
___
Warren Birnbaum : Infrastructure Services
Digital Linux Infrastructure Services
Europe CDT Techn. Operations
Nike Inc. : Mobile +31 6 23902697






On 2/15/16, 12:36 PM, "Lukas Slebodnik"  wrote:

>On (15/02/16 09:34), Birnbaum, Warren (ETW) wrote:
>>Hello,
>>
>>I would like to get freeipa to work with a proxy solution ( I currently
>>have this working with an active directory/no trust authentication and
>>sudo but no HBAC) including HBAC.  I can get sudo to work but not HBAC.
>>I see there is a ticket for this as a new enhancement  #4634 but wanted
>>to confirm that there isn't another way to accomplish this.
>>
>>Here is my current configuration for proxy and this works OK:
>>
>>[domain/mikey.com]
>>sudo_provider = ipa
>>ipa_domain = va2.b2c.mikey.com
>>id_provider = ipa
>>auth_provider = ipa
>>access_provider = ipa
>>ipa_hostname = ip-10-12-177-28.va2.b2c.mikey.com
>>chpass_provider = ipa
>>ipa_server = _srv_, ip-10-12-177-24.va2.b2c.mikey.com
>>ldap_tls_cacert = /etc/ipa/ca.crt
>>
>>id_provider = proxy
>>proxy_lib_name = files
>>auth_provider = ldap
>>reconnection_retries = 3
>>ldap_uri = ldap://adldaplb.mikey.com
>>ldap_search_base = dc=ad,dc=mikey,dc=com?subtree?
>>ldap_schema = AD
>>ldap_default_authtok_type = password
>>ldap_network_timeout = 120
>>ldap_opt_timeout = 120
>>ldap_search_timeout = 120
>>ldap_id_use_start_tls = false
>>ldap_user_object_class = user
>>ldap_group_object_class = group
>>ldap_user_name = sAMAccountName
>>enumerate = true
>>ldap_referrals = true
>>ldap_tls_reqcert = allow
>>ldap_tls_cacertdir = /etc/openldap/cacerts
>>ldap_access_filter = *
>>case_sensitive = false
>>lookup_family_order = ipv4_only
>>dns_resolver_timeout = 30
>>cache_credentials = false
>>
>This configuration file is a little bit suspicious to me.
>There is mixed/overriden id_provider ipa and proxy + some parts from AD.
>
>HBAC can work only with IPA users or trusted AD users (IPA AD trust)
>HBAC cannot work with id_provider ldap, proxy or AD.
>You can achieve something similar with GPO and ad provider.
>
>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

Re: [Freeipa-users] Question about ldap proxy/AD + sudo + HBAC

[Lukas Slebodnik]

On (15/02/16 09:34), Birnbaum, Warren (ETW) wrote:
>Hello,
>
>I would like to get freeipa to work with a proxy solution ( I currently have 
>this working with an active directory/no trust authentication and sudo but no 
>HBAC) including HBAC.  I can get sudo to work but not HBAC.  I see there is a 
>ticket for this as a new enhancement  #4634 but wanted to confirm that there 
>isn't another way to accomplish this.
>
>Here is my current configuration for proxy and this works OK:
>
>[domain/mikey.com]
>sudo_provider = ipa
>ipa_domain = va2.b2c.mikey.com
>id_provider = ipa
>auth_provider = ipa
>access_provider = ipa
>ipa_hostname = ip-10-12-177-28.va2.b2c.mikey.com
>chpass_provider = ipa
>ipa_server = _srv_, ip-10-12-177-24.va2.b2c.mikey.com
>ldap_tls_cacert = /etc/ipa/ca.crt
>
>id_provider = proxy
>proxy_lib_name = files
>auth_provider = ldap
>reconnection_retries = 3
>ldap_uri = ldap://adldaplb.mikey.com
>ldap_search_base = dc=ad,dc=mikey,dc=com?subtree?
>ldap_schema = AD
>ldap_default_authtok_type = password
>ldap_network_timeout = 120
>ldap_opt_timeout = 120
>ldap_search_timeout = 120
>ldap_id_use_start_tls = false
>ldap_user_object_class = user
>ldap_group_object_class = group
>ldap_user_name = sAMAccountName
>enumerate = true
>ldap_referrals = true
>ldap_tls_reqcert = allow
>ldap_tls_cacertdir = /etc/openldap/cacerts
>ldap_access_filter = *
>case_sensitive = false
>lookup_family_order = ipv4_only
>dns_resolver_timeout = 30
>cache_credentials = false
>
This configuration file is a little bit suspicious to me.
There is mixed/overriden id_provider ipa and proxy + some parts from AD.

HBAC can work only with IPA users or trusted AD users (IPA AD trust)
HBAC cannot work with id_provider ldap, proxy or AD.
You can achieve something similar with GPO and ad provider.

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

Re: [Freeipa-users] BIND apparently not loading ldap.so

[Petr Spacek]

On 12.2.2016 20:49, Chris Lajoie wrote:
> On 02/12/2016 12:53 AM, Petr Spacek wrote:
>> On 11.2.2016 19:32, Chris Lajoie wrote:
>>> On 02/11/2016 02:46 AM, Petr Spacek wrote:
 What version of BIND and bind-dyndb-ldap packages are you using? $ rpm
 -q bind bind-dyndb-ldap
>>> bind-9.9.4-29.el7_2.2.x86_64 bind-dyndb-ldap-8.0-1.el7.x86_64
 I'm not sure how exactly the logging magic in BIND works so I would
 recommend you to to run BIND using command: $ named -g -u named and
 check output in the console to see if it contains line like
 'bind-dyndb-ldap version 8.0 compiled at 16:09:02 Jan 20 2016,
 compiler 5.3.1 20151207 (Red Hat 5.3.1-2)'
>>> I get nothing like that. Here is the output I get from running named:
>>> https://gist.github.com/ctlajoie/0ed4e97e72aec3172a8d
>> Oh, wait, it seems that you are using views!
>>
>> Generally we do not test bind-dyndb-ldap with views so there be dragons.
>>
>> Could you share your named.conf with us?
>>
>> If you do not want to send it to mailing list feel free to send it to me
>> privately. My GPG key is attached just for the case you wish to encrypt it.
> 
> Sure. I do not see anything in my named.conf besides the ldap password (which
> I changed) that should be kept private.
> https://gist.github.com/ctlajoie/827a2ec9cfa70e3a1ebd
> 
> Not sure if it matters any more though.. I was able to get it working by
> commenting out  the view parts and leaving only the zones. Unfortunately the
> plugin seems unable or unwilling to load if there are any views present at
> all. I also tried placing the dynamic-db section inside of one of the views.
> named will accept the configuration and start up, but again there are no ldap
> log messages.
> 
> I would really like to use ldap as the backend for my DNS configuration... its
> heirarchical nature seems (to me) to be a good fit for storing that type of
> thing. It is surprising to me that almost nobody else does it this way (from
> what I can tell). I suppose if I want to do it then I will need to run
> seperate instances of bind, either on different servers or the same server
> using different ports for each instance, and doing some NATing with iptables.
> Either method complicates things more than I would like...
> 
> Can you speculate on why there would be no log messages at all when the ldap
> plugin fails to load (if that is indeed what is happening)?
> If there was something in the log it would have saved me quite a bit of time
> investigating this. Thank you for helping me track down the problem.

Interesting, this is a bug in integration with BIND.

It works just fine if dynamic-db part is inside a view {};. If there is no
view explicitly defined then BIND is using implicit view "_default".

It does not work if you have some views explicitly defined and dynamic-db
section is defined outside of any view. It means that dynamic-db section does
not belong to any view and init() is not called for it.

So, workaround is to put dynamic-db section to a view.

I hope it helps.

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

Re: [Freeipa-users] Question about ldap proxy/AD + sudo + HBAC

[Birnbaum, Warren (ETW)]

Hi Jakub,

Thanks but I have sudo working OK.  What I am trying make work is HBAC.
That I can¹t get to work with the proxy hack.  Is there a way to do that?

Thanks,

Warren


___
Warren Birnbaum : Infrastructure Services
Digital Linux Infrastructure Services
Europe CDT Techn. Operations
Nike Inc. : Mobile +31 6 23902697






On 2/15/16, 11:31 AM, "freeipa-users-boun...@redhat.com on behalf of Jakub
Hrozek" 
wrote:

>On Mon, Feb 15, 2016 at 09:34:33AM +, Birnbaum, Warren (ETW) wrote:
>> Hello,
>> 
>> I would like to get freeipa to work with a proxy solution ( I currently
>>have this working with an active directory/no trust authentication and
>>sudo but no HBAC) including HBAC.  I can get sudo to work but not HBAC.
>>I see there is a ticket for this as a new enhancement  #4634 but wanted
>>to confirm that there isn't another way to accomplish this.
>> 
>> Here is my current configuration for proxy and this works OK:
>
>I've used the proxy hack to enable sudo for local (=/etc/passwd) users
>with LDAP sudoers and it just worked. Can you try following:
>https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO
>and see which part does not work?
>
>-- 
>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] Question about ldap proxy/AD + sudo + HBAC

[Jakub Hrozek]

On Mon, Feb 15, 2016 at 09:34:33AM +, Birnbaum, Warren (ETW) wrote:
> Hello,
> 
> I would like to get freeipa to work with a proxy solution ( I currently have 
> this working with an active directory/no trust authentication and sudo but no 
> HBAC) including HBAC.  I can get sudo to work but not HBAC.  I see there is a 
> ticket for this as a new enhancement  #4634 but wanted to confirm that there 
> isn't another way to accomplish this.
> 
> Here is my current configuration for proxy and this works OK:

I've used the proxy hack to enable sudo for local (=/etc/passwd) users
with LDAP sudoers and it just worked. Can you try following:
https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO
and see which part does not work?

-- 
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] Failed to setup replica, slapi_ldap_bind fails

[Filip Pytloun]

I am using Ubuntu 16.04 (Xenial), there's no /etc/openldap

Here's complete debug log of replica install:
http://pastebin.com/38zi5MWd

Now I noticed following, don't know if it can directly relate to this issue:

ipa : DEBUGstderr=ldap_initialize( 
ldap://idm02.tcpcloud.eu:389/??base )
ldap_modify: Server is unwilling to perform (53)
 
ipa : CRITICAL Failed to load indices.ldif: Command 
''/usr/bin/ldapmodify' '-v' '-f' '/usr/share/ipa/indices.ldif' '-H' 
'ldap://idm02.tcpcloud.eu:389' '-x' '-D' 'cn=Directory Manager' '-y' 
'/tmp/tmpIV39iM'' returned non-zero exit status 53

On 2016/02/15 11:06, Ludwig Krispenz wrote:
> 
> On 02/12/2016 06:22 PM, Filip Pytloun wrote:
> >Following is in /etc/ldap/ldap.conf on both servers (only URI differs):
> what is your OS, do you also have a /etc/openldap/ldap.conf
> 
> ldapsearch and the replication connection shoudl use the same openldap
> libraries and so it is strange that -ZZ works and indside ds doesn't.
> 
> At what point did your replica install fail, is there any hint in the
> replica install log ?
> >
> >TLS_CACERT /etc/ipa/ca.crt
> >TLS_REQCERT allow
> >URI ldaps://idm02.tcpcloud.eu
> >BASE dc=tcpcloud,dc=eu
> >
> >As ldapsearch is passing just fine on both nodes, I don't suppose
> >ldap.conf is wrong.
> >I also tried to set TLS_REQCERT to allow just to be sure (in case that
> >bad cert is provided).
> >
> >On 2016/02/12 16:57, Ludwig Krispenz wrote:
> >>On 02/12/2016 03:35 PM, Filip Pytloun wrote:
> >>>It's the same as for idm01:
> >>>
> >>>[12/Feb/2016:15:24:26 +0100] NSMMReplicationPlugin - 
> >>>agmt="cn=meToidm01.tcpcloud.eu" (idm01:389): Replication bind with SIMPLE 
> >>>auth failed: LDAP error -11 (Connect error) ((unknown error code))
> >>>[12/Feb/2016:15:24:27 +0100] slapi_ldap_bind - Error: could not send 
> >>>startTLS request: error -11 (Connect error) errno 0 (Success)
> >>you can get this connect error if the client side cannot verify the cert the
> >>server sends, could you check what you have in f
> >>
> >>>In access logs I can't read much interesting, just that TLS connection 
> >>>happened from idm01:
> >>>
> >>>[12/Feb/2016:15:33:11 +0100] conn=14 fd=64 slot=64 connection from 
> >>>185.22.97.19 to 172.10.10.192
> >>>[12/Feb/2016:15:33:11 +0100] conn=14 op=0 EXT oid="1.3.6.1.4.1.1466.20037" 
> >>>name="startTLS"
> >>>[12/Feb/2016:15:33:11 +0100] conn=14 op=0 RESULT err=0 tag=120 nentries=0 
> >>>etime=0
> >>>[12/Feb/2016:15:33:11 +0100] conn=14 TLS1.2 128-bit AES-GCM
> >>>[12/Feb/2016:15:33:11 +0100] conn=14 op=-1 fd=64 closed - B1
> >>>[12/Feb/2016:15:33:59 +0100] conn=15 fd=64 slot=64 connection from 
> >>>185.22.97.19 to 172.10.10.192
> >>>[12/Feb/2016:15:33:59 +0100] conn=15 op=0 EXT oid="1.3.6.1.4.1.1466.20037" 
> >>>name="startTLS"
> >>>[12/Feb/2016:15:33:59 +0100] conn=15 op=0 RESULT err=0 tag=120 nentries=0 
> >>>etime=0
> >>>[12/Feb/2016:15:34:00 +0100] conn=15 TLS1.2 128-bit AES-GCM
> >>>[12/Feb/2016:15:34:00 +0100] conn=15 op=-1 fd=64 closed - B1
> >>>
> >>>On 2016/02/12 15:22, Ludwig Krispenz wrote:
> On 02/12/2016 03:06 PM, Filip Pytloun wrote:
> >Hello,
> >
> >even when enabling replication logging, I get nothing useful in logs:
> >
> >[12/Feb/2016:14:57:00 +0100] NSMMReplicationPlugin - 
> >agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): Trying secure startTLS 
> >slapi_ldap_init_ext
> >[12/Feb/2016:14:57:00 +0100] NSMMReplicationPlugin - 
> >agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): binddn = cn=replication 
> >manager,cn=config,  passwd = {AES-some_encrypted_password
> >[12/Feb/2016:14:57:01 +0100] slapi_ldap_bind - Error: could not send 
> >startTLS request: error -11 (Connect error) errno 0 (Success)
> >[12/Feb/2016:14:57:01 +0100] NSMMReplicationPlugin - 
> >agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): Replication bind with 
> >SIMPLE auth failed: LDAP error -11 (Connect error) ((unknown error code))
> >[12/Feb/2016:14:57:01 +0100] NSMMReplicationPlugin - 
> >agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): Disconnected from the 
> >consumer
> what is in the access and error logs of idm02 for this time ?
> >But I can bind just fine manually:
> >
> >ldapsearch -D "cn=replication manager,cn=config" -w some_password -b 
> >cn=config -h idm02 -ZZ
> >
> >I am starting to be clueless, nobody has an idea what could be wrong?
> >
> >- DNS including PTR records are set up fine
> >- /etc/hosts is setup fine
> >- conncheck passes fine between nodes
> >- I can bind manually just fine
> >
> >On 2016/02/08 18:05, Filip Pytloun wrote:
> >>Hello,
> >>
> >>I have a weird issue setting up FreeIPA replica. Conncheck passes fine
> >>but at the end of ipa-replica-install I always get following error:
> >>
> >>slapi_ldap_bind -Error: could not send startTLS request: error -11
> >>(Connect error) errno 0 (Success)
> >>
> >>on both master and replica without any 

Re: [Freeipa-users] Connection closed by UNKNOWN

[Jakub Hrozek]

On Mon, Feb 15, 2016 at 10:24:23AM +0530, Rakesh Rajasekharan wrote:
> hbac seems to be fine
> 
> 
> ipa hbactest --user=q-temp --host=x.x.x.x --service=sshd
> 
> Access granted: True
> 
>   Matched rules: allow_all
> 
> 
> I see this in the sssd.log
> 
> (Mon Feb 15 04:49:18 2016) [sssd[nss]] [sss_ncache_check_str] (0x2000):
> Checking negative cache for [NCE/USER/xyz.com/q-temp]
> (Mon Feb 15 04:49:18 2016) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100):
> Requesting info for [q-t...@xyz.com]
> (Mon Feb 15 04:49:18 2016) [sssd[nss]] [check_cache] (0x0400): Cached entry
> is valid, returning..
> (Mon Feb 15 04:49:18 2016) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0400):
> Returning info for user [q-t...@xyz.com]
> (Mon Feb 15 04:49:18 2016) [sssd[nss]] [client_recv] (0x0200): Client
> disconnected!
> (Mon Feb 15 04:49:18 2016) [sssd[nss]] [client_destructor] (0x2000):
> Terminated client [0x23d2f80][20]
> (Mon Feb 15 04:49:27 2016) [sssd[nss]] [sbus_get_sender_id_send] (0x2000):
> Not a sysbus message, quit

What does /var/log/secure say?

Also you pasted the NSS log, the domain log would be more useful here.

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Failed to setup replica, slapi_ldap_bind fails

[Ludwig Krispenz]

On 02/12/2016 06:22 PM, Filip Pytloun wrote:

Following is in /etc/ldap/ldap.conf on both servers (only URI differs):

what is your OS, do you also have a /etc/openldap/ldap.conf

ldapsearch and the replication connection shoudl use the same openldap 
libraries and so it is strange that -ZZ works and indside ds doesn't.


At what point did your replica install fail, is there any hint in the 
replica install log ?


TLS_CACERT /etc/ipa/ca.crt
TLS_REQCERT allow
URI ldaps://idm02.tcpcloud.eu
BASE dc=tcpcloud,dc=eu

As ldapsearch is passing just fine on both nodes, I don't suppose
ldap.conf is wrong.
I also tried to set TLS_REQCERT to allow just to be sure (in case that
bad cert is provided).

On 2016/02/12 16:57, Ludwig Krispenz wrote:

On 02/12/2016 03:35 PM, Filip Pytloun wrote:

It's the same as for idm01:

[12/Feb/2016:15:24:26 +0100] NSMMReplicationPlugin - 
agmt="cn=meToidm01.tcpcloud.eu" (idm01:389): Replication bind with SIMPLE auth 
failed: LDAP error -11 (Connect error) ((unknown error code))
[12/Feb/2016:15:24:27 +0100] slapi_ldap_bind - Error: could not send startTLS 
request: error -11 (Connect error) errno 0 (Success)

you can get this connect error if the client side cannot verify the cert the
server sends, could you check what you have in f


In access logs I can't read much interesting, just that TLS connection happened 
from idm01:

[12/Feb/2016:15:33:11 +0100] conn=14 fd=64 slot=64 connection from 185.22.97.19 
to 172.10.10.192
[12/Feb/2016:15:33:11 +0100] conn=14 op=0 EXT oid="1.3.6.1.4.1.1466.20037" 
name="startTLS"
[12/Feb/2016:15:33:11 +0100] conn=14 op=0 RESULT err=0 tag=120 nentries=0 
etime=0
[12/Feb/2016:15:33:11 +0100] conn=14 TLS1.2 128-bit AES-GCM
[12/Feb/2016:15:33:11 +0100] conn=14 op=-1 fd=64 closed - B1
[12/Feb/2016:15:33:59 +0100] conn=15 fd=64 slot=64 connection from 185.22.97.19 
to 172.10.10.192
[12/Feb/2016:15:33:59 +0100] conn=15 op=0 EXT oid="1.3.6.1.4.1.1466.20037" 
name="startTLS"
[12/Feb/2016:15:33:59 +0100] conn=15 op=0 RESULT err=0 tag=120 nentries=0 
etime=0
[12/Feb/2016:15:34:00 +0100] conn=15 TLS1.2 128-bit AES-GCM
[12/Feb/2016:15:34:00 +0100] conn=15 op=-1 fd=64 closed - B1

On 2016/02/12 15:22, Ludwig Krispenz wrote:

On 02/12/2016 03:06 PM, Filip Pytloun wrote:

Hello,

even when enabling replication logging, I get nothing useful in logs:

[12/Feb/2016:14:57:00 +0100] NSMMReplicationPlugin - 
agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): Trying secure startTLS 
slapi_ldap_init_ext
[12/Feb/2016:14:57:00 +0100] NSMMReplicationPlugin - 
agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): binddn = cn=replication 
manager,cn=config,  passwd = {AES-some_encrypted_password
[12/Feb/2016:14:57:01 +0100] slapi_ldap_bind - Error: could not send startTLS 
request: error -11 (Connect error) errno 0 (Success)
[12/Feb/2016:14:57:01 +0100] NSMMReplicationPlugin - 
agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): Replication bind with SIMPLE auth 
failed: LDAP error -11 (Connect error) ((unknown error code))
[12/Feb/2016:14:57:01 +0100] NSMMReplicationPlugin - 
agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): Disconnected from the consumer

what is in the access and error logs of idm02 for this time ?

But I can bind just fine manually:

ldapsearch -D "cn=replication manager,cn=config" -w some_password -b cn=config 
-h idm02 -ZZ

I am starting to be clueless, nobody has an idea what could be wrong?

- DNS including PTR records are set up fine
- /etc/hosts is setup fine
- conncheck passes fine between nodes
- I can bind manually just fine

On 2016/02/08 18:05, Filip Pytloun wrote:

Hello,

I have a weird issue setting up FreeIPA replica. Conncheck passes fine
but at the end of ipa-replica-install I always get following error:

slapi_ldap_bind -Error: could not send startTLS request: error -11
(Connect error) errno 0 (Success)

on both master and replica without any further explanation in logs.

/etc/ldap.conf is correctly setup before ipa-replica-install and IPA CA
certificate is installed in system CA bundle so TLS should work just
fine.

Also I can manually connect just fine from replica to master and back so
it's not a network or LDAP client issue.

Replica agreement looks like this: http://pastebin.com/FT3p3KUk

freeipa-server 4.1.4
389-ds 1.3.4.5

Has anyone idea where to look at?

Filip



--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project



--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project


--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Active Directory Trust = filter users

[Sumit Bose]

On Mon, Feb 15, 2016 at 11:10:41AM +0200, Alexander Bokovoy wrote:
> On Mon, 15 Feb 2016, Sumit Bose wrote:
> >On Fri, Feb 12, 2016 at 10:49:36PM +0200, Alexander Bokovoy wrote:
> >>On Fri, 12 Feb 2016, Jakub Hrozek wrote:
> >>>On Fri, Feb 12, 2016 at 01:29:47PM +0200, Alexander Bokovoy wrote:
> On Fri, 12 Feb 2016, w...@dds.nl wrote:
> >Hi all,
> >
> >Yes, you can filter out certain SIDs--> I tried, but cannot get it to
> >work. For example, I don't need "Domain Users":
> >
> >Found out the SID by:
> >
> >[root@suacri10103 ~]# getent group domain\ us...@ad.example.org
> >domain us...@example.org:*:1012600513:someu...@ad.example.org
> >[root@suacri10103 ~]# ldbsearch -H
> >/var/lib/sss/db/cache_ipa.ad%s/example.org.ldb  gidNumber=1012600513 |
> >grep objectSIDString
> >asq: Unable to register control with rootdse!
> >objectSIDString: S-1-5-21-1447349426-2906170142-3196411423-513
> >
> >and put the SID in the blacklist; yes it is blacklisted:
> >
> >admin01@ipa ~]$ ipa trust-show ad.example.com --all | grep "SID blacklist
> >incoming"
> > SID blacklist incoming: S-1-5-20,
> >S-1-5-21-1447349426-2906170142-3196411423-513, S-1-5-3, S-1-5-2, S-1-5-1,
> >S-1-5-7, S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, S-1-5-17, S-1-5-16,
> >S-1-5-15, S-1-5-14, S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2,
> >S-1-1, S-1-0, S-1-5-19, S-1-5-18
> >
> >However, the group is still there if I do a n "id 
> >someu...@ad.example.com"
> >(yep, whiped cache, restarted ipa etc.)
> >
> >Shouldn't the group be disappeared since the SID is blacklisted...?
> Only from Kerberos tickets. I don't think SSSD in ipa_server_mode
> consults this list. Instead, when AD users logins with Kerberos ticket,
> the resulting ticket already has blacklisted SIDs filtered out by IPA
> KDC and SSSD will see that these tickets' MS-PAC doesn't have additional
> groups in it.
> >>>
> >>>Alexander, do you think this would make a reasonable RFE?
> >>For non-logged-in case? Yes, it certainly makes sense as it would be
> >>consistent with KDC then. The only potential issue is that we'd lose
> >>'true' group membership for IPA CLI/Web UI operations as removing
> >>'Domain us...@ad.test' would make it impossible to assign anything to
> >>'Domain us...@ad.test' in ID overrides and external group members, but
> >>given it is actually filtered out at the level of a trust boundary, may
> >>be this is exactly what a person would like to achieve?
> >
> >yes, I think we have to add support in SSSD for this to be consistent
> >with the group memberships we get from the PAC. But since we in general
> >cannot ignore the groups completely it might be sufficient to just label
> >the filtered groups as non-POSIX groups in the cache (maybe we need an
> >additional flag to indicate that the group is really filtered out to
> >make sure that future lookup schemes which might include non-POSIX
> >groups will ignore the filtered groups as well).
> Marking it non-POSIX wouldn't prevent nested group membership, though.
> This obviously needs more thought...

yes, but I think this would be in agreement to the filtering in the PAC
because here we filter only the SID from this blacklist and not the SIDs
of groups nested in the related group.

bye,
Sumit

> 
> >Btw, the 'Domain Users' group is a bad example here, because it is in
> >general the primary group of the AD users in AD and hence listed in the
> >PAC as primary group. If you filter 'Domain Users' we have to reject all
> >Kerberos request because the resulting PAC will not have a primary
> >group.
> Yep. Though I've seen some environments where people did actually change
> the primary group for AD users to something else. AD environments can be
> broken in a multitude of interesting ways. ;)
> 
> -- 
> / 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] Question about ldap proxy/AD + sudo + HBAC

[Birnbaum, Warren (ETW)]

Hello,

I would like to get freeipa to work with a proxy solution ( I currently have 
this working with an active directory/no trust authentication and sudo but no 
HBAC) including HBAC.  I can get sudo to work but not HBAC.  I see there is a 
ticket for this as a new enhancement  #4634 but wanted to confirm that there 
isn't another way to accomplish this.

Here is my current configuration for proxy and this works OK:

[domain/mikey.com]
sudo_provider = ipa
ipa_domain = va2.b2c.mikey.com
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = ip-10-12-177-28.va2.b2c.mikey.com
chpass_provider = ipa
ipa_server = _srv_, ip-10-12-177-24.va2.b2c.mikey.com
ldap_tls_cacert = /etc/ipa/ca.crt

id_provider = proxy
proxy_lib_name = files
auth_provider = ldap
reconnection_retries = 3
ldap_uri = ldap://adldaplb.mikey.com
ldap_search_base = dc=ad,dc=mikey,dc=com?subtree?
ldap_schema = AD
ldap_default_authtok_type = password
ldap_network_timeout = 120
ldap_opt_timeout = 120
ldap_search_timeout = 120
ldap_id_use_start_tls = false
ldap_user_object_class = user
ldap_group_object_class = group
ldap_user_name = sAMAccountName
enumerate = true
ldap_referrals = true
ldap_tls_reqcert = allow
ldap_tls_cacertdir = /etc/openldap/cacerts
ldap_access_filter = *
case_sensitive = false
lookup_family_order = ipv4_only
dns_resolver_timeout = 30
cache_credentials = false


Thanks for your help,

Warren Birnbaum
-- 
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 Trust = filter users

[Alexander Bokovoy]

On Mon, 15 Feb 2016, Sumit Bose wrote:

On Fri, Feb 12, 2016 at 10:49:36PM +0200, Alexander Bokovoy wrote:

On Fri, 12 Feb 2016, Jakub Hrozek wrote:
>On Fri, Feb 12, 2016 at 01:29:47PM +0200, Alexander Bokovoy wrote:
>>On Fri, 12 Feb 2016, w...@dds.nl wrote:
>>>Hi all,
>>>
>>>Yes, you can filter out certain SIDs--> I tried, but cannot get it to
>>>work. For example, I don't need "Domain Users":
>>>
>>>Found out the SID by:
>>>
>>>[root@suacri10103 ~]# getent group domain\ us...@ad.example.org
>>>domain us...@example.org:*:1012600513:someu...@ad.example.org
>>>[root@suacri10103 ~]# ldbsearch -H
>>>/var/lib/sss/db/cache_ipa.ad%s/example.org.ldb  gidNumber=1012600513 |
>>>grep objectSIDString
>>>asq: Unable to register control with rootdse!
>>>objectSIDString: S-1-5-21-1447349426-2906170142-3196411423-513
>>>
>>>and put the SID in the blacklist; yes it is blacklisted:
>>>
>>>admin01@ipa ~]$ ipa trust-show ad.example.com --all | grep "SID blacklist
>>>incoming"
>>> SID blacklist incoming: S-1-5-20,
>>>S-1-5-21-1447349426-2906170142-3196411423-513, S-1-5-3, S-1-5-2, S-1-5-1,
>>>S-1-5-7, S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, S-1-5-17, S-1-5-16,
>>>S-1-5-15, S-1-5-14, S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2,
>>>S-1-1, S-1-0, S-1-5-19, S-1-5-18
>>>
>>>However, the group is still there if I do a n "id someu...@ad.example.com"
>>>(yep, whiped cache, restarted ipa etc.)
>>>
>>>Shouldn't the group be disappeared since the SID is blacklisted...?
>>Only from Kerberos tickets. I don't think SSSD in ipa_server_mode
>>consults this list. Instead, when AD users logins with Kerberos ticket,
>>the resulting ticket already has blacklisted SIDs filtered out by IPA
>>KDC and SSSD will see that these tickets' MS-PAC doesn't have additional
>>groups in it.
>
>Alexander, do you think this would make a reasonable RFE?
For non-logged-in case? Yes, it certainly makes sense as it would be
consistent with KDC then. The only potential issue is that we'd lose
'true' group membership for IPA CLI/Web UI operations as removing
'Domain us...@ad.test' would make it impossible to assign anything to
'Domain us...@ad.test' in ID overrides and external group members, but
given it is actually filtered out at the level of a trust boundary, may
be this is exactly what a person would like to achieve?


yes, I think we have to add support in SSSD for this to be consistent
with the group memberships we get from the PAC. But since we in general
cannot ignore the groups completely it might be sufficient to just label
the filtered groups as non-POSIX groups in the cache (maybe we need an
additional flag to indicate that the group is really filtered out to
make sure that future lookup schemes which might include non-POSIX
groups will ignore the filtered groups as well).

Marking it non-POSIX wouldn't prevent nested group membership, though.
This obviously needs more thought...


Btw, the 'Domain Users' group is a bad example here, because it is in
general the primary group of the AD users in AD and hence listed in the
PAC as primary group. If you filter 'Domain Users' we have to reject all
Kerberos request because the resulting PAC will not have a primary
group.

Yep. Though I've seen some environments where people did actually change
the primary group for AD users to something else. AD environments can be
broken in a multitude of interesting ways. ;)

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

Re: [Freeipa-users] Active Directory Trust = filter users

[Sumit Bose]

On Fri, Feb 12, 2016 at 10:49:36PM +0200, Alexander Bokovoy wrote:
> On Fri, 12 Feb 2016, Jakub Hrozek wrote:
> >On Fri, Feb 12, 2016 at 01:29:47PM +0200, Alexander Bokovoy wrote:
> >>On Fri, 12 Feb 2016, w...@dds.nl wrote:
> >>>Hi all,
> >>>
> >>>Yes, you can filter out certain SIDs--> I tried, but cannot get it to
> >>>work. For example, I don't need "Domain Users":
> >>>
> >>>Found out the SID by:
> >>>
> >>>[root@suacri10103 ~]# getent group domain\ us...@ad.example.org
> >>>domain us...@example.org:*:1012600513:someu...@ad.example.org
> >>>[root@suacri10103 ~]# ldbsearch -H
> >>>/var/lib/sss/db/cache_ipa.ad%s/example.org.ldb  gidNumber=1012600513 |
> >>>grep objectSIDString
> >>>asq: Unable to register control with rootdse!
> >>>objectSIDString: S-1-5-21-1447349426-2906170142-3196411423-513
> >>>
> >>>and put the SID in the blacklist; yes it is blacklisted:
> >>>
> >>>admin01@ipa ~]$ ipa trust-show ad.example.com --all | grep "SID blacklist
> >>>incoming"
> >>> SID blacklist incoming: S-1-5-20,
> >>>S-1-5-21-1447349426-2906170142-3196411423-513, S-1-5-3, S-1-5-2, S-1-5-1,
> >>>S-1-5-7, S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, S-1-5-17, S-1-5-16,
> >>>S-1-5-15, S-1-5-14, S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2,
> >>>S-1-1, S-1-0, S-1-5-19, S-1-5-18
> >>>
> >>>However, the group is still there if I do a n "id someu...@ad.example.com"
> >>>(yep, whiped cache, restarted ipa etc.)
> >>>
> >>>Shouldn't the group be disappeared since the SID is blacklisted...?
> >>Only from Kerberos tickets. I don't think SSSD in ipa_server_mode
> >>consults this list. Instead, when AD users logins with Kerberos ticket,
> >>the resulting ticket already has blacklisted SIDs filtered out by IPA
> >>KDC and SSSD will see that these tickets' MS-PAC doesn't have additional
> >>groups in it.
> >
> >Alexander, do you think this would make a reasonable RFE?
> For non-logged-in case? Yes, it certainly makes sense as it would be
> consistent with KDC then. The only potential issue is that we'd lose
> 'true' group membership for IPA CLI/Web UI operations as removing
> 'Domain us...@ad.test' would make it impossible to assign anything to
> 'Domain us...@ad.test' in ID overrides and external group members, but
> given it is actually filtered out at the level of a trust boundary, may
> be this is exactly what a person would like to achieve?

yes, I think we have to add support in SSSD for this to be consistent
with the group memberships we get from the PAC. But since we in general
cannot ignore the groups completely it might be sufficient to just label
the filtered groups as non-POSIX groups in the cache (maybe we need an
additional flag to indicate that the group is really filtered out to
make sure that future lookup schemes which might include non-POSIX
groups will ignore the filtered groups as well).

Btw, the 'Domain Users' group is a bad example here, because it is in
general the primary group of the AD users in AD and hence listed in the
PAC as primary group. If you filter 'Domain Users' we have to reject all
Kerberos request because the resulting PAC will not have a primary
group.

bye,
Sumit

> -- 
> / Alexander Bokovoy
> 
> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project