from:"Brendan Kearney"

[Freeipa-users] bind-dyndb-ldap replication errors

2017-04-12 Thread Brendan Kearney


list members,

i am using bind-dyndb-ldap without freeipa, and i consistently get the 
below errors in my logs:


update_zone (syncrepl) failed for master zone DN 
'idnsName=24.168.192.in-addr.arpa.,cn=dns,ou=Daemons,dc=bpk2,dc=com'. 
Zones can be outdated, run `rndc reload`: unexpected error


the zone that has issue varies, but it is always a zone that allows 
dynamic updates.  it seems that some replication event fails and a 
manual resync of things has to be performed.  any ideas what might be 
going on?


fedora 24, with nearly all recent updates
bind-9.10.4-3.P6.fc24.x86_64
bind-dyndb-ldap-10.1-1.fc24.x86_64
openldap-2.4.44-1.fc24.x86_64

i have multi master replication configured between 2 masters, and no 
other replication events seem to fail.  i am not sure where to look for 
issues.


named.conf:
dynamic-db "bpk2.com" {
library "ldap.so";
arg "uri ldap://192.168.88.1;;
arg "base cn=dns,ou=Daemons,dc=bpk2,dc=com";


arg "auth_method sasl";
arg "sasl_mech GSSAPI";
arg "sasl_realm BPK2.COM";
arg "krb5_keytab FILE:/etc/named.keytab";
arg "krb5_principal DNS/server1.bpk2.com";
arg "ldap_hostname server1.bpk2.com";

arg "fake_mname dns.bpk2.com.";
arg "dyn_update yes";
arg "connections 2";
};

zone config:
dn: idnsName=24.168.192.in-addr.arpa.,cn=dns,ou=Daemons,dc=bpk2,dc=com
dnsttl: 3600
idnsallowdynupdate: TRUE
idnsallowquery: any;
idnsallowsyncptr: TRUE
idnsname: 24.168.192.in-addr.arpa.
idnssoaexpire: 604800
idnssoaminimum: 86400
idnssoamname: dns.bpk2.com.
idnssoarefresh: 10800
idnssoaretry: 900
idnssoarname: root.bpk2.com.
idnssoaserial: 1491999811
idnsupdatepolicy: grant dhcp wildcard * any;
idnszoneactive: TRUE
nsrecord: dns.bpk2.com.
objectclass: top
objectclass: idnsZone
objectclass: idnsRecord

any help would be appreciated.

thanks,

brendan

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

Re: [Freeipa-users] Can mount NFS, but user only gets the permission question marks

2017-03-02 Thread Brendan Kearney


On 03/02/2017 08:43 AM, Kees Bakker wrote:

On 02-03-17 13:34, Brendan Kearney wrote:

On 03/02/2017 05:40 AM, Kees Bakker wrote:

On 24-02-17 14:38, Brendan Kearney wrote:

On 02/24/2017 03:33 AM, Kees Bakker wrote:

On 23-02-17 15:39, Brendan Kearney wrote:

On 02/23/2017 09:11 AM, Kees Bakker wrote:

On 23-02-17 13:51, Brendan Kearney wrote:

On 02/23/2017 07:32 AM, Kees Bakker wrote:

On 22-02-17 17:33, Brendan Kearney wrote:

On 02/22/2017 10:26 AM, Kees Bakker wrote:

On 22-02-17 14:05, Brendan Kearney wrote:

On 02/22/2017 05:23 AM, Kees Bakker wrote:

On 21-02-17 19:49, Brendan Kearney wrote:

On 02/21/2017 10:57 AM, Kees Bakker wrote:

Hey,

Maybe one of the NFS users on this list could give me a hint what
could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos.

I've set up an NFS server and I can mount the NFS directory on my client. So, 
I'm
guessing that setting up Kerberos principal was done correctly.

However, only root can actually access the mounted contents. Any other user
only sees question marks as shown below.

The mount command is simple.
$ sudo mount -v -t nfs srv1.example.com:/home /nfshome
mount.nfs: timeout set for Tue Feb 21 16:36:39 2017
mount.nfs: trying text-based options 
'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30'

On the server side /etc/exports looks like this.
/home*(rw,sync,sec=krb5i,no_subtree_check)

$ sudo mount |grep nfs
srv1.example.com:/home on /nfshome type nfs4 
(rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45)

$ sudo ls -ld /nfshome
drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome
$ sudo ls -l /nfshome
total 0
drwxr-xr-x 1 keesb  keesb  116 jan 27 12:56 keesb

$ ls -l /nfshome
ls: cannot access '/nfshome': Permission denied
$ ls -l / | grep nfshome
ls: cannot access '/nfshome': Permission denied
d?   ? ??   ?? nfshome


[...]

Continuing story...

I've tried various things in the meantime. I've set up two test environments 
with virtual
machines (virtualbox).
* with Fedora 25; this works.
* with Ubuntu 16.04; I'm getting the same problem (permission denied and 
question marks).

I also looked at the verbose output of rpc.gssd, it gives

ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS 
failure.  Minor code may provide more information) - Can't find client 
principal keesb@REALM in cache collection

does the actual error message say @REALM, or did you substitute that to obscure 
sensitive info?  if it does actually say @REALM, then you are missing a config 
directive somewhere, that specifies the kerberos realm.

Be assured that I'm using the real thing.


getting credentials for client with uid 60001 for server srv1.example.com
getting credentials for client with uid 60001 for server srv1.example.com
WARNING: Failed to create krb5 context for user with uid 60001 for server 
srv1.example.com

So rpc.gssd is trying to create a krb5 context. It succeeds for uid=0 but not 
for another
user.

Log when root is listing the NFS directory
Mar  2 14:23:52 clnt1 rpc.gssd[3612]: handling gssd upcall 
(/run/rpc_pipefs/nfs/clnt14)
Mar  2 14:23:52 clnt1 rpc.gssd[3612]: handle_gssd_upcall: 'mech=krb5 uid=0 
service=* enctypes=18,17,16,23,3,1,2 '
Mar  2 14:23:52 clnt1 rpc.gssd[3612]: handling krb5 upcall 
(/run/rpc_pipefs/nfs/clnt14)
Mar  2 14:23:52 clnt1 rpc.gssd[3612]: process_krb5_upcall: service is '*'
Mar  2 14:23:52 clnt1 rpc.gssd[3612]: Full hostname for 'srv1.example.com' is 
'srv1.example.com'
Mar  2 14:23:52 clnt1 rpc.gssd[3612]: Full hostname for 'clnt1.example.com' is 
'clnt1.example.com'
Mar  2 14:23:52 clnt1 rpc.gssd[3612]: No key table entry found for 
CLNT1.REALM$@REALM while getting keytab entry for 'CLNT1.REALM$@REALM'
Mar  2 14:23:52 clnt1 rpc.gssd[3612]: No key table entry found for 
root/clnt1.example.com@REALM while getting keytab entry for 
'root/clnt1.example.com@REALM'
Mar  2 14:23:52 clnt1 rpc.gssd[3612]: No key table entry found for 
nfs/clnt1.example.com@REALM while getting keytab entry for 
'nfs/clnt1.example.com@REALM'
Mar  2 14:23:52 clnt1 rpc.gssd[3612]: Success getting keytab entry for 
'host/clnt1.example.com@REALM'
Mar  2 14:23:52 clnt1 rpc.gssd[3612]: INFO: Credentials in CC 
'FILE:/tmp/krb5ccmachine_REALM' are good until 1488535153
Mar  2 14:23:52 clnt1 rpc.gssd[3612]: INFO: Credentials in CC 
'FILE:/tmp/krb5ccmachine_REALM' are good until 1488535153
Mar  2 14:23:52 clnt1 rpc.gssd[3612]: using FILE:/tmp/krb5ccmachine_REALM as 
credentials cache for machine creds
Mar  2 14:23:52 clnt1 rpc.gssd[3612]: using environment variable to select krb5 
ccache FILE:/tmp/krb5ccmachine_REALM
Mar  2 14:23:52 clnt1 rpc.gssd[3612]: creating context using fsuid 0 (save_uid 
0)
Mar  2 14:23:52 clnt1 rpc.gssd[3612]: creating tcp client for server 
srv1.example.com
Mar  2 14:23:52 clnt1 rpc.gssd[3612]: DEBUG: port already set to 2049
Mar  2 14:23:52

Re: [Freeipa-users] Can mount NFS, but user only gets the permission question marks

2017-03-02 Thread Brendan Kearney

On 03/02/2017 05:40 AM, Kees Bakker wrote:

On 24-02-17 14:38, Brendan Kearney wrote:

On 02/24/2017 03:33 AM, Kees Bakker wrote:

On 23-02-17 15:39, Brendan Kearney wrote:

On 02/23/2017 09:11 AM, Kees Bakker wrote:

On 23-02-17 13:51, Brendan Kearney wrote:

On 02/23/2017 07:32 AM, Kees Bakker wrote:

On 22-02-17 17:33, Brendan Kearney wrote:

On 02/22/2017 10:26 AM, Kees Bakker wrote:

On 22-02-17 14:05, Brendan Kearney wrote:

On 02/22/2017 05:23 AM, Kees Bakker wrote:

On 21-02-17 19:49, Brendan Kearney wrote:

On 02/21/2017 10:57 AM, Kees Bakker wrote:

Hey,

Maybe one of the NFS users on this list could give me a hint what
could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos.

I've set up an NFS server and I can mount the NFS directory on my client. So,
I'm
guessing that setting up Kerberos principal was done correctly.

However, only root can actually access the mounted contents. Any other user
only sees question marks as shown below.

The mount command is simple.
$ sudo mount -v -t nfs srv1.example.com:/home /nfshome
mount.nfs: timeout set for Tue Feb 21 16:36:39 2017
mount.nfs: trying text-based options
'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30'

On the server side /etc/exports looks like this.
/home*(rw,sync,sec=krb5i,no_subtree_check)

$ sudo mount |grep nfs
srv1.example.com:/home on /nfshome type nfs4
(rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45)

$ sudo ls -ld /nfshome
drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome
$ sudo ls -l /nfshome
total 0
drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb

$ ls -l /nfshome
ls: cannot access '/nfshome': Permission denied
$ ls -l / | grep nfshome
ls: cannot access '/nfshome': Permission denied
d? ? ?? ?? nfshome

[...]

Continuing story...

I've tried various things in the meantime. I've set up two test environments
with virtual
machines (virtualbox).
* with Fedora 25; this works.
* with Ubuntu 16.04; I'm getting the same problem (permission denied and
question marks).

I also looked at the verbose output of rpc.gssd, it gives

ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS
failure. Minor code may provide more information) - Can't find client
principal keesb@REALM in cache collection
does the actual error message say @REALM, or did you substitute that to
obscure sensitive info? if it does actually say @REALM, then you are
missing a config directive somewhere, that specifies the kerberos realm.

getting credentials for client with uid 60001 for server srv1.example.com
getting credentials for client with uid 60001 for server srv1.example.com
WARNING: Failed to create krb5 context for user with uid 60001 for server
srv1.example.com

But the user really did get a TGT.

$ klist
Ticket cache: KEYRING:persistent:60001:60001
Default principal: ke...@example.com

Valid starting ExpiresService principal
02-03-17 10:25:25 03-03-17 10:25:22 krbtgt/example@example.com

So, still no solution for Ubuntu + freeipa + nfs.

BTW. I've enabled verbosity in /etc/idmapd.conf. The logging tells me it is OK.
However,
there is only any output when root (uid 0) does a NFS directory lookup. When a
regular
user tries to stat the NFS directory it does not even get to the point where id
mapping is
done.

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

Re: [Freeipa-users] Can mount NFS, but user only gets the permission question marks

2017-02-24 Thread Brendan Kearney

On 02/24/2017 03:33 AM, Kees Bakker wrote:

On 23-02-17 15:39, Brendan Kearney wrote:

On 02/23/2017 09:11 AM, Kees Bakker wrote:

On 23-02-17 13:51, Brendan Kearney wrote:

On 02/23/2017 07:32 AM, Kees Bakker wrote:

On 22-02-17 17:33, Brendan Kearney wrote:

On 02/22/2017 10:26 AM, Kees Bakker wrote:

On 22-02-17 14:05, Brendan Kearney wrote:

On 02/22/2017 05:23 AM, Kees Bakker wrote:

On 21-02-17 19:49, Brendan Kearney wrote:

On 02/21/2017 10:57 AM, Kees Bakker wrote:

Hey,

Maybe one of the NFS users on this list could give me a hint what
could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos.

I've set up an NFS server and I can mount the NFS directory on my client. So,
I'm
guessing that setting up Kerberos principal was done correctly.

However, only root can actually access the mounted contents. Any other user
only sees question marks as shown below.

On the server side /etc/exports looks like this.
/home*(rw,sync,sec=krb5i,no_subtree_check)

$ sudo ls -ld /nfshome
drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome
$ sudo ls -l /nfshome
total 0
drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb

$ ls -l /nfshome
ls: cannot access '/nfshome': Permission denied
$ ls -l / | grep nfshome
ls: cannot access '/nfshome': Permission denied
d? ? ?? ?? nfshome

sec=krb* means that the user accessing the mount has to authenticate with a
kerberos ticket, and has to be the user or in the group granted access to the
share. from the looks of things, the user did not authenticate, and that is
why the permissions are question marks. check the kerberos tickets that the
user has (klist output). Otherwise, the ownership might be user and group that
the client machine does not recognize (think posix user/group that is not in
sync between the NFS server and the client)

Thanks for the reply.

In this case the user _is_ authenticated.
keesb@client1:~$ klist
Ticket cache: KEYRING:persistent:60001:60001
Default principal: ke...@example.com

Valid starting ExpiresService principal
22-02-17 09:20:30 23-02-17 09:20:25 krbtgt/example@example.com

no, the user has a TGT. a nfs/host.domain.tld@REALM ticket is needed to
authenticate.

(( I'm trying to catch up on the acronyms. TGT. Reading wikipedia now. ))

What other grants could be needed? HBAC Rules?

Do I need an nfs principal for the client? (I didn't think so, but many HOWTO's
say so [2]. Anyway, it
doesn't help to get access for the user.)

there are principals to create and keytabs to be updated on hte NFS sever, if
not done already.

I did create a principal for the NFS server (using ipa service-add) and
add to the keytab on the NFS server (using ipa-getkeytab) ...
root@srv1# klist -ke
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
--
1 host/srv1.example@example.com (aes256-cts-hmac-sha1-96)
1 host/srv1.example@example.com (aes128-cts-hmac-sha1-96)
1 nfs/srv1.example@example.com (aes256-cts-hmac-sha1-96)
1 nfs/srv1.example@example.com (aes128-cts-hmac-sha1-96)

Is this what you mean?

yes, if that is done, the server side components should be done for kerberos.
have you set things up in /etc/idmapd.conf so your domain, REALM, etc are setup?

I don't think that a change of idmapd.conf (on the NFS server) is needed
because all host
names are FQDN and everything is in one and the same REALM.

NFS needs to know how to map a user object to an ID and groups. identities
established by kerberos do not directly translate to users. usually some sort
of directory services are leveraged in order to accomplish this, though PAM and
things like that can be used to. by setting things in idmapd.conf, you are
telling NFS who to translate kerberos identities into usernames, so ownership
and permissions can be sync'd.

Both the NFS server and the client are configured as FreeIPA client.
On the server the users are known (through PAM, SSSD). Only user
"ubuntu" is a local (/etc/passwd) user. All other users are defined on
the IPA server.

root@srv1:~# ls -l /home
total 0
drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb
drwxr-xr-x 1 ubuntu ubuntu 142 aug 17 2016 ubuntu
root@srv1:~# ls -ln /home
total 0
drwxr-xr-x 1 60001 60001 116 jan 27 12:56 keesb
drwxr-xr-x 1 1000 1000 142 aug 17 2016 ubuntu

On the client, same story

root@client1:~# ls -l /nfshome
total 0
drwxr-xr-x 1 keesb keesb 116 ja

Re: [Freeipa-users] sudo NOPASSWD for a single command

2017-02-23 Thread Brendan Kearney


On 02/23/2017 09:43 AM, Auerbach, Steven wrote:

sudo vgs >> statresults.txt


should be sudo /sbin/vgs >> statresults.txt since that is what sudo 
allows.  its almost like exact match for strings.


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

Re: [Freeipa-users] Can mount NFS, but user only gets the permission question marks

2017-02-23 Thread Brendan Kearney

On 02/23/2017 09:11 AM, Kees Bakker wrote:

On 23-02-17 13:51, Brendan Kearney wrote:

On 02/23/2017 07:32 AM, Kees Bakker wrote:

On 22-02-17 17:33, Brendan Kearney wrote:

On 02/22/2017 10:26 AM, Kees Bakker wrote:

On 22-02-17 14:05, Brendan Kearney wrote:

On 02/22/2017 05:23 AM, Kees Bakker wrote:

On 21-02-17 19:49, Brendan Kearney wrote:

On 02/21/2017 10:57 AM, Kees Bakker wrote:

Hey,

Maybe one of the NFS users on this list could give me a hint what
could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos.

I've set up an NFS server and I can mount the NFS directory on my client. So,
I'm
guessing that setting up Kerberos principal was done correctly.

However, only root can actually access the mounted contents. Any other user
only sees question marks as shown below.

On the server side /etc/exports looks like this.
/home*(rw,sync,sec=krb5i,no_subtree_check)

$ sudo ls -ld /nfshome
drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome
$ sudo ls -l /nfshome
total 0
drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb

$ ls -l /nfshome
ls: cannot access '/nfshome': Permission denied
$ ls -l / | grep nfshome
ls: cannot access '/nfshome': Permission denied
d? ? ?? ?? nfshome

Thanks for the reply.

In this case the user _is_ authenticated.
keesb@client1:~$ klist
Ticket cache: KEYRING:persistent:60001:60001
Default principal: ke...@example.com

Valid starting ExpiresService principal
22-02-17 09:20:30 23-02-17 09:20:25 krbtgt/example@example.com

no, the user has a TGT. a nfs/host.domain.tld@REALM ticket is needed to
authenticate.

(( I'm trying to catch up on the acronyms. TGT. Reading wikipedia now. ))

What other grants could be needed? HBAC Rules?

Do I need an nfs principal for the client? (I didn't think so, but many HOWTO's
say so [2]. Anyway, it
doesn't help to get access for the user.)

there are principals to create and keytabs to be updated on hte NFS sever, if
not done already.

Is this what you mean?

yes, if that is done, the server side components should be done for kerberos.
have you set things up in /etc/idmapd.conf so your domain, REALM, etc are setup?

I don't think that a change of idmapd.conf (on the NFS server) is needed
because all host
names are FQDN and everything is in one and the same REALM.

On the client, same story

root@client1:~# ls -l /nfshome
total 0
drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb
drwxr-xr-x 1 ubuntu ubuntu 142 aug 17 2016 ubuntu
root@client1:~# ls -l

Re: [Freeipa-users] Can mount NFS, but user only gets the permission question marks

2017-02-23 Thread Brendan Kearney

On 02/23/2017 07:32 AM, Kees Bakker wrote:

On 22-02-17 17:33, Brendan Kearney wrote:

On 02/22/2017 10:26 AM, Kees Bakker wrote:

On 22-02-17 14:05, Brendan Kearney wrote:

On 02/22/2017 05:23 AM, Kees Bakker wrote:

On 21-02-17 19:49, Brendan Kearney wrote:

On 02/21/2017 10:57 AM, Kees Bakker wrote:

Hey,

Maybe one of the NFS users on this list could give me a hint what
could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos.

I've set up an NFS server and I can mount the NFS directory on my client. So,
I'm
guessing that setting up Kerberos principal was done correctly.

However, only root can actually access the mounted contents. Any other user
only sees question marks as shown below.

On the server side /etc/exports looks like this.
/home*(rw,sync,sec=krb5i,no_subtree_check)

$ sudo ls -ld /nfshome
drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome
$ sudo ls -l /nfshome
total 0
drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb

$ ls -l /nfshome
ls: cannot access '/nfshome': Permission denied
$ ls -l / | grep nfshome
ls: cannot access '/nfshome': Permission denied
d? ? ?? ?? nfshome

Thanks for the reply.

In this case the user _is_ authenticated.
keesb@client1:~$ klist
Ticket cache: KEYRING:persistent:60001:60001
Default principal: ke...@example.com

Valid starting ExpiresService principal
22-02-17 09:20:30 23-02-17 09:20:25 krbtgt/example@example.com

no, the user has a TGT. a nfs/host.domain.tld@REALM ticket is needed to
authenticate.

(( I'm trying to catch up on the acronyms. TGT. Reading wikipedia now. ))

What other grants could be needed? HBAC Rules?

Do I need an nfs principal for the client? (I didn't think so, but many HOWTO's
say so [2]. Anyway, it
doesn't help to get access for the user.)

there are principals to create and keytabs to be updated on hte NFS sever, if
not done already.

Is this what you mean?

yes, if that is done, the server side components should be done for kerberos.
have you set things up in /etc/idmapd.conf so your domain, REALM, etc are setup?

I don't think that a change of idmapd.conf (on the NFS server) is needed
because all host
names are FQDN and everything is in one and the same REALM.
NFS needs to know how to map a user object to an ID and groups.
identities established by kerberos do not directly translate to users.
usually some sort of directory services are leveraged in order to
accomplish this, though PAM and things like that can be used to. by
setting things in idmapd.conf, you are telling NFS who to translate
kerberos identities into usernames, so ownership and permissions can be
sync'd.

then the user should be able to pull the ticket for auth.

Sorry to ask, but how do I do that? On the client, I suppose, and by the user ??

keesb@client1$ kinit nfs/srv1.example@example.com
Password for nfs/srv1.example@example.com:

But I don't have a password for that. Hmm.

there is no need to init on the client side, as long as the TGT is obtained.
you should never need to init the nfs/blah.. on the client side.

OK
So, it seems to me that all the basics are setup correctly. The mount succeeds.
The user
has a TGT and still the (non-root) user cannot even stat the mount point, nor
the directory
entry itself.

What puzzles me is that root can see everything, also without a TGT.
the mount will succeed, but the user does not have access because NFS

Re: [Freeipa-users] Can mount NFS, but user only gets the permission question marks

2017-02-22 Thread Brendan Kearney

On 02/22/2017 10:26 AM, Kees Bakker wrote:

On 22-02-17 14:05, Brendan Kearney wrote:

On 02/22/2017 05:23 AM, Kees Bakker wrote:

On 21-02-17 19:49, Brendan Kearney wrote:

On 02/21/2017 10:57 AM, Kees Bakker wrote:

Hey,

Maybe one of the NFS users on this list could give me a hint what
could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos.

I've set up an NFS server and I can mount the NFS directory on my client. So,
I'm
guessing that setting up Kerberos principal was done correctly.

However, only root can actually access the mounted contents. Any other user
only sees question marks as shown below.

On the server side /etc/exports looks like this.
/home*(rw,sync,sec=krb5i,no_subtree_check)

$ sudo ls -ld /nfshome
drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome
$ sudo ls -l /nfshome
total 0
drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb

$ ls -l /nfshome
ls: cannot access '/nfshome': Permission denied
$ ls -l / | grep nfshome
ls: cannot access '/nfshome': Permission denied
d? ? ?? ?? nfshome

Thanks for the reply.

In this case the user _is_ authenticated.
keesb@client1:~$ klist
Ticket cache: KEYRING:persistent:60001:60001
Default principal: ke...@example.com

Valid starting ExpiresService principal
22-02-17 09:20:30 23-02-17 09:20:25 krbtgt/example@example.com

no, the user has a TGT. a nfs/host.domain.tld@REALM ticket is needed to
authenticate.

(( I'm trying to catch up on the acronyms. TGT. Reading wikipedia now. ))

What other grants could be needed? HBAC Rules?

Do I need an nfs principal for the client? (I didn't think so, but many HOWTO's
say so [2]. Anyway, it
doesn't help to get access for the user.)

there are principals to create and keytabs to be updated on hte NFS sever, if
not done already.

Is this what you mean?
yes, if that is done, the server side components should be done for
kerberos. have you set things up in /etc/idmapd.conf so your domain,
REALM, etc are setup?

then the user should be able to pull the ticket for auth.

Sorry to ask, but how do I do that? On the client, I suppose, and by the user ??

keesb@client1$ kinit nfs/srv1.example@example.com
Password for nfs/srv1.example@example.com:

But I don't have a password for that. Hmm.
there is no need to init on the client side, as long as the TGT is
obtained. you should never need to init the nfs/blah.. on the client side.

Furthermore, I'm guessing that the host principle which I got after
ipa-client-install is
good enough. (This [1] wiki suggests that I need to do a ipa-getkeytab for it,
which I
did not do.)
# klist -ke
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
--
1 host/client1.example@example.com (aes256-cts-hmac-sha1-96)
1 host/client1.example@example.com (aes128-cts-hmac-sha1-96)

[1] http://wiki.linux-nfs.org/wiki/index.php/NFS_and_FreeIPA
[2] https://www.lisenet.com/2016/kerberised-nfs-server-on-rhel-7/

http://www.itp.uzh.ch/~dpotter/howto/kerberos

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

Re: [Freeipa-users] Can mount NFS, but user only gets the permission question marks

2017-02-22 Thread Brendan Kearney

On 02/22/2017 05:23 AM, Kees Bakker wrote:

On 21-02-17 19:49, Brendan Kearney wrote:

On 02/21/2017 10:57 AM, Kees Bakker wrote:

Hey,

Maybe one of the NFS users on this list could give me a hint what
could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos.

I've set up an NFS server and I can mount the NFS directory on my client. So,
I'm
guessing that setting up Kerberos principal was done correctly.

However, only root can actually access the mounted contents. Any other user
only sees question marks as shown below.

On the server side /etc/exports looks like this.
/home*(rw,sync,sec=krb5i,no_subtree_check)

$ sudo ls -ld /nfshome
drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome
$ sudo ls -l /nfshome
total 0
drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb

$ ls -l /nfshome
ls: cannot access '/nfshome': Permission denied
$ ls -l / | grep nfshome
ls: cannot access '/nfshome': Permission denied
d? ? ?? ?? nfshome

Thanks for the reply.

In this case the user _is_ authenticated.
keesb@client1:~$ klist
Ticket cache: KEYRING:persistent:60001:60001
Default principal: ke...@example.com

Valid starting ExpiresService principal
22-02-17 09:20:30 23-02-17 09:20:25 krbtgt/example@example.com
no, the user has a TGT. a nfs/host.domain.tld@REALM ticket is needed to
authenticate.

What other grants could be needed? HBAC Rules?

Do I need an nfs principal for the client? (I didn't think so, but many HOWTO's
say so [2]. Anyway, it
doesn't help to get access for the user.)
there are principals to create and keytabs to be updated on hte NFS
sever, if not done already. then the user should be able to pull the
ticket for auth.

[1] http://wiki.linux-nfs.org/wiki/index.php/NFS_and_FreeIPA
[2] https://www.lisenet.com/2016/kerberised-nfs-server-on-rhel-7/

http://www.itp.uzh.ch/~dpotter/howto/kerberos

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

Re: [Freeipa-users] Can mount NFS, but user only gets the permission question marks

2017-02-21 Thread Brendan Kearney

On 02/21/2017 10:57 AM, Kees Bakker wrote:

Hey,

Maybe one of the NFS users on this list could give me a hint what
could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos.

I've set up an NFS server and I can mount the NFS directory on my client. So,
I'm
guessing that setting up Kerberos principal was done correctly.

However, only root can actually access the mounted contents. Any other user
only sees question marks as shown below.

On the server side /etc/exports looks like this.
/home*(rw,sync,sec=krb5i,no_subtree_check)

$ sudo ls -ld /nfshome
drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome
$ sudo ls -l /nfshome
total 0
drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb

$ ls -l /nfshome
ls: cannot access '/nfshome': Permission denied
$ ls -l / | grep nfshome
ls: cannot access '/nfshome': Permission denied
d? ? ?? ?? nfshome

sec=krb* means that the user accessing the mount has to authenticate
with a kerberos ticket, and has to be the user or in the group granted
access to the share. from the looks of things, the user did not
authenticate, and that is why the permissions are question marks. check
the kerberos tickets that the user has (klist output). Otherwise, the
ownership might be user and group that the client machine does not
recognize (think posix user/group that is not in sync between the NFS
server and the client)

brendan

--
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] bind-dyndb-ldap and replication requirements

2016-11-09 Thread Brendan Kearney

i am asking this for a friend who is trying to figure out how to get 
bind-dyndb-ldap working against openldap on ubuntu.  she does not have 
replication between two or more ldap instances, and needs to figure out 
the minimum requirements for bind-dyndb-ldap.  i have been trying to 
help her, but i am unsure about what is needed, as i have n-way multi 
master replication working already.


can anyone provide what the replication requirements are for 
bind-dyndb-ldap?  currently, the SyncRepl module is loaded and the 
overlay is created and configured for the mdb.  i have tried to help get 
olcServerID and olcMirrorMode set in cn=config and 
olcDatabase={2}mdb,cn=config respectively, but some errors were 
encountered there.  is there a best practices doc that we can review?


the environment, as best i can tell is ubuntu, openldap 2.4.42 and bind 
9.  exact os and bind versions are not known right now.


thanks,

brendan kearney

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

Re: [Freeipa-users] bind-dyndb-ldap issues

2016-10-12 Thread Brendan Kearney


On 10/12/2016 02:35 AM, Petr Spacek wrote:

Hello,

these are debug messages and are harmless. Apparently you have verbose/debug
messages enabled in named.conf:

 arg "verbose_checks yes";

If you want to get rid of these messages, just remove the line.

What version of bind-dyndb-ldap are you using?

Sufficiently new versions should use SyncRepl to pull all data from LDAP to
memory (on start) so the read performance should be nearly identical as with
plain BIND.

Of course, writes/DNS updates will generate load on your LDAP server so the
server needs to handle the load.

Petr^2 Spacek

On 11.10.2016 20:41, Brendan Kearney wrote:

i am using bind-dyndb-ldap on fedora 24 without FreeIPA, and continue to have
my logs swamped with errors about "check failed" from settings.c and fwd.c.  i
am completely up to date with every package, so the latest versions of
everything are installed.

[settings.c : 420: setting_update_from_ldap_entry] check failed: ignore
[settings.c : 436: setting_update_from_ldap_entry] check failed: ignore
[fwd.c : 378: fwd_setting_isexplicit] check failed: not found

i have two boxes running a named instance each, in a "master/master" config.
each has the zone data configured per below.  the uri refers to the local ip
of each server.

 dynamic-db "bpk2.com" {
 library "ldap.so";
 arg "uri ldap://192.168.88.1/;;
 arg "base cn=dns,ou=Daemons,dc=bpk2,dc=com";
 arg "auth_method simple";
 arg "bind_dn cn=dnsUser,dc=bpk2,dc=com";
 arg "password dnsPass";

 arg "fake_mname server1.bpk2.com.";
 arg "dyn_update yes";
 arg "connections 2";
 arg "verbose_checks yes";
 };

 zone "." IN {
 type hint;
 file "named.ca";
 };

 include "/etc/named.rfc1912.zones";

my dns container is defined in openldap as such:

dn: cn=dns,ou=Daemons,dc=bpk2,dc=com
cn: dns
idnspersistentsearch: FALSE
idnszonerefresh: 30
objectclass: top
objectclass: nsContainer
objectclass: idnsConfigObject

where and how can i find the source of my issue?  these issues are causing
performance issues on the rest of my network.  because of these errors, ldap
throws errors about deferred operations for binding, too many executing, and
pending operations.  additionally, recursion also seems to be impacted.  this
is noticed most when streaming content.  buffering, stuttering and pixelation
are seen in the video streams.  it could be the swamping of logs killing I/O
or the actual recurision, but 100% the video issues are related.  the log
events match up exactly with the buffering.

i had this issue with bind-dyndb-ldap and fedora 20 up until i recently
upgraded.  i went from F20 to F24, and put things on nice new SSDs, instead of
spinning disks.  the problem followed the upgrade.  are there configuration
items i am missing?  are there tweaks i can do to improve something?  how do i
get rid of these errors, so dns performance (or the log swamping) is not
affecting the rest of my network?

thank you,

brendan


i am running 10.1.1 on F24.

why or how would those error logs be related to LDAP seeing an influx of 
updates, that wind up causing LDAP operations to queue up and require 
pended transactions, etc?are there tweaks and tuning options i 
should have in my LDAP to manage this?


thanks,

brendan

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

2016-10-11 Thread Brendan Kearney

i am using bind-dyndb-ldap on fedora 24 without FreeIPA, and continue to 
have my logs swamped with errors about "check failed" from settings.c 
and fwd.c.  i am completely up to date with every package, so the latest 
versions of everything are installed.


[settings.c : 420: setting_update_from_ldap_entry] check failed: ignore
[settings.c : 436: setting_update_from_ldap_entry] check failed: ignore
[fwd.c : 378: fwd_setting_isexplicit] check failed: not found

i have two boxes running a named instance each, in a "master/master" 
config.  each has the zone data configured per below.  the uri refers to 
the local ip of each server.


dynamic-db "bpk2.com" {
library "ldap.so";
arg "uri ldap://192.168.88.1/;;
arg "base cn=dns,ou=Daemons,dc=bpk2,dc=com";
arg "auth_method simple";
arg "bind_dn cn=dnsUser,dc=bpk2,dc=com";
arg "password dnsPass";

arg "fake_mname server1.bpk2.com.";
arg "dyn_update yes";
arg "connections 2";
arg "verbose_checks yes";
};

zone "." IN {
type hint;
file "named.ca";
};

include "/etc/named.rfc1912.zones";

my dns container is defined in openldap as such:

dn: cn=dns,ou=Daemons,dc=bpk2,dc=com
cn: dns
idnspersistentsearch: FALSE
idnszonerefresh: 30
objectclass: top
objectclass: nsContainer
objectclass: idnsConfigObject

where and how can i find the source of my issue?  these issues are 
causing performance issues on the rest of my network.  because of these 
errors, ldap throws errors about deferred operations for binding, too 
many executing, and pending operations.  additionally, recursion also 
seems to be impacted.  this is noticed most when streaming content.  
buffering, stuttering and pixelation are seen in the video streams.  it 
could be the swamping of logs killing I/O or the actual recurision, but 
100% the video issues are related.  the log events match up exactly with 
the buffering.


i had this issue with bind-dyndb-ldap and fedora 20 up until i recently 
upgraded.  i went from F20 to F24, and put things on nice new SSDs, 
instead of spinning disks.  the problem followed the upgrade.  are there 
configuration items i am missing?  are there tweaks i can do to improve 
something?  how do i get rid of these errors, so dns performance (or the 
log swamping) is not affecting the rest of my network?


thank you,

brendan

--
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] non-authoritative tricks for DNS resolution

2016-07-18 Thread Brendan Kearney

On 07/18/2016 06:12 AM, Petr Spacek wrote:

On 18.7.2016 03:25, Sullivan, Daniel [AAA] wrote:

Would a DNS view (bind) work?

http://docstore.mik.ua/orelly/networking_2ndEd/dns/ch10_06.htm

Also, depending on what you are using for NAT, some devices will mangle the
reply payload of A record lookups as they traverse NAT to avoid haripinning (a
packet going out and then back in the same interface as it traverses NAT).
This is known as DNS doctoring, at least in the world of Cisco.

http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/72273-dns-doctoring-3zones.html

Let me know if either of those will solve your problem. If not, I might have a
misunderstanding of what you are asking.

Dan

On Jul 17, 2016, at 3:36 PM, Brendan Kearney <bpk...@gmail.com> wrote:

i am looking to setup a VPN in order to access some resources, and want to
point my clients at this resource via DNS. the resource i am accessing is
internet resolvable, but i am accessing it via the VPN, and using a NAT for the
VPN (full 1-to-1 or static NAT). i want to have a record in my DNS for this
resource, using its proper name (which i am not authoritative for), but assign
it the IP of my NAT.

say for example, host.domain-ext.tld is the resource i want to access, and it
resolves externally to 1.2.3.4. my VPN NAT would be 192.168.99.137. i want
internal resolution of DNS to point to 192.168.99.137 so the network routing
takes my internal clients to the VPN and not out to the internet.

i am using isc bind, bind-dyndb-ldap, and fedora, but not freeipa, for dns. how do i
setup the zone and record to accomplish this DNS trick? i have talked with some DNS
gurus and they indicate that i can do something with the "@" record. it seems
that the record i want, would be its own zone, and the @ record would point to the name,
and the SOA would be the NAT IP. i could be wrong about the details, but something like
this is how to setup resolution the way i want.

any pointers would be greatly appreciated.

Background note:
All these DNS tricks are hacks to work around IP routing problem in
configuration you described.

If you really want to use DNS tricks, you can create a DNS zone with name
equal to the you want to override and will this zone with A/ record at
zone apex (@).
The DNS approach has some inherent advantages:

1. All DNS names below the name you want to 'hijack' will not be resolvable in
your network. E.g. if the name is hijacked.example.com. then sub-domains like
anything.hijacked.example.com. will not be resolvable.

2. Your clients will go securely over VPN if and only if they use your local
DNS servers. Any client configured (even accidentally) to use some other DNS
server (e.g. public 8.8.8.8) will get the 'public' address and do not tunnel
the traffic over VPN.

Secure and reliable solution is not to use DNS but solve things on IP layer:
On the network gateway, configure IPSec tunnel (or any other VPN) in a way
that *the original IP address* is routed over VPN.

This does not require any DNS tricks and thus will work regardless of client
configuration.

I hope it helps.

our posture states that we do not route network space that is not ours,
unless exigent circumstances dictate otherwise. we have dedicated
address space to NAT pools, in order to facilitate this. we also forbid
external dns resolution from endpoints, by limiting what can go out to
the roots for recursion. misconfigured clients are not able to perform
DNS resolution. we work with our counterparts on the other side of the
VPN to ensure we are only adding a host record, and that sub-domains are
not a point of failure for our access.

in terms of setting up this zone, how would one construct the ldif to
create it? because i am not using FreeIPA, i do not have the seemingly
built-in tools to perform this function. any reading material on the
subject is welcomed.

thanks,

brendan

--
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] non-authoritative tricks for DNS resolution

2016-07-17 Thread Brendan Kearney

i am looking to setup a VPN in order to access some resources, and want 
to point my clients at this resource via DNS.  the resource i am 
accessing is internet resolvable, but i am accessing it via the VPN, and 
using a NAT for the VPN (full 1-to-1 or static NAT).  i want to have a 
record in my DNS for this resource, using its proper name (which i am 
not authoritative for), but assign it the IP of my NAT.


say for example, host.domain-ext.tld is the resource i want to access, 
and it resolves externally to 1.2.3.4.  my VPN NAT would be 
192.168.99.137.  i want internal resolution of DNS to point to 
192.168.99.137 so the network routing takes my internal clients to the 
VPN and not out to the internet.


i am using isc bind, bind-dyndb-ldap, and fedora, but not freeipa, for 
dns.  how do i setup the zone and record to accomplish this DNS trick?  
i have talked with some DNS gurus and they indicate that i can do 
something with the "@" record.  it seems that the record i want, would 
be its own zone, and the @ record would point to the name, and the SOA 
would be the NAT IP.  i could be wrong about the details, but something 
like this is how to setup resolution the way i want.


any pointers would be greatly appreciated.

thanks,

brendan

--
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] separating authoritative servers from recursive servers

2015-10-06 Thread Brendan Kearney


On 10/06/2015 07:42 AM, Petr Spacek wrote:

On 6.10.2015 03:40, Brendan Kearney wrote:

i have two bind instances in somewhat of a multi-master server arrangement,
where they share the same ldap backend via bind-dyndb-ldap.  currently, they
are authoritative and recursive servers, and i want to change things up a
bit.  i want to move the recursive function to a third device.  for this, i
believe i need to set a forwarder for the two current servers.  i believe i
would do this by adding the idnsForwarders object (with value) on the OU that
is the idnsConfigObject.

i am looking for a sanity check, to ensure that i am not overlooking something
important.  are there any steps i am missing?  i want the current two
instances to be authoritative for all my forward and reverse zones, and use
the forwarder for all recursion.  the forwarder instance is already running,
and is setup to answer queries from only the two current instances.  i think i
just need to point the current instances to the forwarder instance, and turn
off recursion on them.

Hmm, I think that there is some confusion about terms we use.

Pure authoritative server would give out answers only for zones it is
authoritative for (i.e. zones defined in /etc/named.conf or LDAP) and refuse
to answer all other queries. Is that what are you looking for?

In contrast, a recursive server would answer query for any zone. If you really
want to separate authoritative and recursive roles, then you should:

(0. As always: Make sure that delegation for all your zones is correct.)
1. Set up recursive-only server. Add 'allow-recursion { IP_range; };' to
named.conf.
2. Reconfigure all clients to use the recursive-only server and not to ask
authoritative servers directly.
3. Reconfigure authoritative servers by adding allow-recursion { none; }; to
named.conf.

No changes in LDAP should be necessary.

Does it answer your question?

i want to have separation of duties in my dns infrastructure.  the 
intention is to have clients point to the current instances of dns for 
all records.  behind the scenes, i want to have those current instances 
be authoritative for my internal zones, and for queries that they are 
not authoritative for, they reach out to the third server/instance for 
recursive queries.  the third server/instance for recursive queries 
should not be contacted by clients.  the end result is a hierarchy of 
roles for the dns instances.


from the bind docs:
The forwarding facility can be used to create a large site-wide cache on 
a few servers, reducing traffic over links to external name servers. It 
can also be used to allow queries by servers that do not have direct 
access to the Internet, but wish to look up exterior names anyway. 
Forwarding occurs only on those queries for which the server is not 
authoritative and does not have the answer in its cache.


I plan to remove external access for the two current dns instances and 
force them to use the instance set as the forwarder for all external or 
recursive lookups. it seems that the idnsForwarders attribute is where i 
start working on this.


-- 
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] separating authoritative servers from recursive servers

2015-10-05 Thread Brendan Kearney

i have two bind instances in somewhat of a multi-master server 
arrangement, where they share the same ldap backend via 
bind-dyndb-ldap.  currently, they are authoritative and recursive 
servers, and i want to change things up a bit.  i want to move the 
recursive function to a third device.  for this, i believe i need to set 
a forwarder for the two current servers.  i believe i would do this by 
adding the idnsForwarders object (with value) on the OU that is the 
idnsConfigObject.


i am looking for a sanity check, to ensure that i am not overlooking 
something important.  are there any steps i am missing?  i want the 
current two instances to be authoritative for all my forward and reverse 
zones, and use the forwarder for all recursion.  the forwarder instance 
is already running, and is setup to answer queries from only the two 
current instances.  i think i just need to point the current instances 
to the forwarder instance, and turn off recursion on them.


thanks in advance,

brendan

--
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] GSSAPI authentication for libvirt VNC

2015-09-01 Thread Brendan Kearney


On 08/30/2015 12:49 PM, Marin Bernard wrote:

Hi,

I followed the instructions from freeipa.org (
https://www.freeipa.org/page/Libvirt_with_VNC_Consoles) to make libvirt
and VNC use GSSAPI authentication with FreeIPA. The libvirt part works
fine: I'm able to SSO the KVM host using TCP + SASL. However, I'm
unable to get a VNC connection to any guest: both virt-manager and virt
-viewer fail. The former speaks about a "closed or refused connection",
and the latter just closes.


On the KVM host, each VNC login attempt adds the following record to
the systemd journal:

qemu-kvm[3202]: GSSAPI server step 1


On the host, libvirt starts qemu-kvm with a SASL VNC, which seems
correct to me:

# ps -aux | grep qemu-kvm

 -vnc 0.0.0.0:0,sasl 


QEMU may read the VNC keytab

$ ls -l /etc/qemu/
total 4
-rw---. 1 qemu root 458 30 août  15:48 krb5.tab


Contents of /etc/sasl2/qemu-kvm.conf (comments removed)

mech_list: gssapi
keytab: /etc/qemu/krb5.tab


The client seems to grab correct tickets:

$ klist
Ticket cache: KEYRING:persistent:121541:krb_ccache_jjD9A46
Default principal: ma...@cloud.olivarim.com

Valid starting   Expires  Service principal
30/08/2015 16:11:22  31/08/2015 15:34:53  vnc/nice-hkvm-ctrl-01
.core.nice.cloud.olivarim@cloud.olivarim.com
30/08/2015 16:08:12  31/08/2015 15:34:53  libvirt/nice-hkvm-ctr
l-01.core.nice.cloud.olivarim@cloud.olivarim.com

KVM Host is Centos 7.2, up to date.

FreeIPA server is Centos 7.2, up to date, with FreeIPA 4.1.0 rev.
18.el7.centos.4

Client is Fedora 22, up to date.

I tried to disable both the firewall and SELinux but it did not change
anything.

Do you have any clues ?

Thanks!

Marin.


my /etc/sasl2/qemu.conf (note the different file name, may be relevant*):

mech_list: gssapi
keytab: /etc/qemu/qemu.keytab
sasldb_path: /etc/qemu/passwd.db
auxprop_plugin: sasldb

my /etc/sasl2/libvirt.conf:

mech_list: gssapi
keytab: /etc/libvirt/libvirt.keytab

my /etc/qemu/qemu.keytab file has the principal used/needed for VNC 
(vnc/host.domain.tld@REALM).  you can check yours with "klist -Kket 
/path/to/qemu.keytab"


my /etc/libvirt/libvirt.keytab file has the principal used/needed for 
virt-manager or virsh console (libvirt/host.domain.tld@REALM). you can 
check your with "klist -Kket /path/to/libvirt.keytab"


* the name of the file in /etc/sasl2/ is tied to the name of the 
application.  find the sysadmin.html page for Cyrus-SASL-libs, which states:


By default, the Cyrus SASL library reads it's options from 
/usr/lib/sasl2/App.conf (where "App" is the application defined name of 
the application). For instance, Sendmail reads it's configuration from 
"/usr/lib/sasl2/Sendmail.conf" and the sample server application 
included with the library looks in "/usr/lib/sasl2/sample.conf".


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

[Freeipa-users] bind-dyndb-ldap and stub zones

2015-04-02 Thread Brendan Kearney

i am wondering if bind-dyndb-ldap supports stub zones.  below would be a
use case for me.

say i have a network with a lot of external client connectivity (over
leased line, MPLS, VPN, etc).  the clients connections are used for
inbound, outbound or bi-directional traffic (file transfers, web
traffic, data exchange, etc).

because of the size of my network, my already large and complex routing
scheme for my own needs does not need to be made more complex by having
to route my client's address space, so i devote specific networks out of
my address space to 1-to-1 or static NAT addresses.  by doing this, i
can push all that traffic to the vpn endpoints or routers that manage
that connectivity, without having to route foreign networks in the
core.  to make life easier, i want to have DNS names assigned to the NAT
addresses, but the names are not in my authoritative name space, and may
be internet resolvable, should a recursive search be performed.

say i have mydomain.tld registered, and i have 300.555.0.0/16 assigned
(yes, i know that does not exist).  i would devote 300.555.254.0/23 to
these 1-to-1 NATs.  client Example Corp has dedicated connectivity to me
and i want to access their website over that connection.  the site,
www.example.com, is internet resolvable but i dont want to access the
internet accessible site.  i want DNS resolution to point to my NAT, and
take the traffic to the VPN where the NAT occurs and the traffic is
pushed across to the client.

with stub zones, i could create a zone, example.com, put a record for
www into that zone and assign it my 1-to-1 NAT address of 300.555.254.1.
i push my internal requests for that resource towards my vpn or client
connection router, and perform the NAT at that device.  my routing stays
free of foreign networks and the traffic ends up where i want it.

can bind-dyndb-ldap manage stub zones?  how would one create the
necessary ldap entries?  sub zones require some extra work, so i would
imagine stub zones do too, if they are currently supported.

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

Re: [Freeipa-users] freeipa behind a load balancer

2015-03-31 Thread Brendan Kearney

On Tue, 2015-03-31 at 11:07 -0400, Dmitri Pal wrote:
 On 03/31/2015 10:38 AM, Matt . wrote:
  True, but we have some extra later between which does the cli command
  not usable (at least for the moment)
 
  I already know how to share the key's among all servers, that works
  fine, IPA/Apache/Kerberos only doesn't like the other hostname
  (loadbalancer), or the client doesn't understand it.
 
  So fixing this saves me really much more time than doing the another way.
 
 Kerberos is not load balancer friendly. It is something that is a known 
 property of Kerberos.
 I remember MIT mentioning something that they did or might do to help 
 with that so it might make sense to ask this question on the MIT 
 Kerberos user list.
 
 
  Thanks!
 
  Matt
 
  2015-03-31 16:24 GMT+02:00 Petr Spacek pspa...@redhat.com:
  On 31.3.2015 16:10, Matt . wrote:
  HI Petr,
 
  We had a several of reasons why we did that. We wanted to use one
  language for that, and also have formatted returns. There was also
  some security issue which came up.
  I would be very interested in the security reason. If you see any problem 
  with
  'ipa' command or FreeIPA API please send me a private e-mail or contact
  secal...@redhat.com directly.
 
  I could ask you, why does IPA json itself ? if you see what it posts
  and what it gets back as result it makes it much more clear in
  development.
  I do not understand the question, sorry.
 
  If you want to see what 'ipa' command does run it with '-vv' parameter:
  $ ipa -vv user-find
 
  It will print JSON request and reply:
  ipa: INFO: Request: {
   id: 0,
   method: user_find,
   params: [
   [
   null
   ],
   {
   all: false,
   no_members: false,
   pkey_only: false,
   raw: false,
   version: 2.115,
   whoami: false
   }
   ]
  }
  ipa: INFO: Response: {
   error: null,
   id: 0,
   principal: admin@IPA.EXAMPLE,
   result: {
   count: 2,
   result: [
   {
   dn: uid=admin,cn=users,cn=accounts,dc=ipa,dc=example,
   gidnumber: [
   138100
   ],
  ...
 
 
  HTTP loadbalancing is not difficult at all, as we post to the
  webserver I need to have that part only auth right. We do more very
  specific loadbalancing stuff and this is the most easy one as it's
  only webserver forward, but IPA/Kerberos has an issue with the
  principal it seems... it cannot be hard to make that accepted I would
  say.
  If you insist on Kerberos servers behind a load balancer... you will need 
  to
  somehow share the Kerberos key among all servers. I will defer that to
  Kerberos experts here.
 
  I'm still looking for solutions :)
  Sure, but you will save a lot of time and nerves if you simply call 'ipa'
  command :-)
 
  Have a nice day!
 
  Petr^2 Spacek
 
  Cheers,
 
  Matt
 
  2015-03-31 15:58 GMT+02:00 Petr Spacek pspa...@redhat.com:
  On 31.3.2015 15:23, Matt . wrote:
  Hi Petr,
 
  We discussed that before indeed, but SRV is not usable in this case.
 
  My clients are just webservers (apache) doing some executes of CURL
  commands to ipa/json, actually the same commands as the webgui does
  using json, but we curl it.
 
  Do you have a better view now ?
  Yes. If you have seen the previous discussion then you know that it will 
  be
  pretty difficult to do this kind of load balancing.
 
  Why are you not using 'ipa' command or Python API we have instead? Why 
  to use
  CURL and make things more complex?
 
  Petr^2 Spacek
 
  2015-03-31 15:03 GMT+02:00 Petr Spacek pspa...@redhat.com:
  On 31.3.2015 14:35, Matt . wrote:
  Hi Petr,
 
  As this is not my topic it's for me quite simple.
 
  I need to post to /ipa/json through a loadbalancer, nothing more.
 
  i have
 
  ldap-01.domain.tld (ipa1)
  ldap-01.domain.tld (ipa2)
 
  and my loadbalancer is ldap.domain.tld
 
  ldap requests over a loadbalancer are quite simple and working, but
  the json part is more difficult because of the ticket and the dns
  name. I have added a san ldap.domain.tld to the webgui and there is a
  http/ldap.domain.tld service on the ipa server.
 
  I get a nonvalid kerberos ticket when I go through ldap.domain.tld to
  ldap-01.domain.tld, but when I change my script to ldap-01.domain.tld
  after it failed my ticket is OK for ldap-01.domain.tld and works.
 
  Is this enough information for you ?
  Well, I still do not understand the use case. What are your clients? 
  Are you
  using 'ipa' command to do something? Or some other clients?
 
  Usually the best thing is to use DNS SRV records because it works even 
  with
  geographically distributed clusters and does not have single point of 
  failure
  (the load balancer).
 
  This requires clients with support for DNS SRV but if your machines 
  are using
  SSSD then you do not need to change anything and it should just work.

Re: [Freeipa-users] freeipa behind a load balancer

2015-03-31 Thread Brendan Kearney

On Tue, 2015-03-31 at 17:51 +0200, Matt . wrote:
 Hi Brendan,
 
 Yes thanks for your great explanation, I have done that indeed. But in
 some strange way, with only a 401 in access_log of apache I get a Non
 valid ticket when I connect through my loadbalancer. I don't go by
 my loadbalancer but through it (NAT) or should it go by/next to it ?
 
 I think we can get this fixed :)
 
 Thanks!
 
 Matt
 
 2015-03-31 17:41 GMT+02:00 Brendan Kearney bpk...@gmail.com:
  On Tue, 2015-03-31 at 11:07 -0400, Dmitri Pal wrote:
  On 03/31/2015 10:38 AM, Matt . wrote:
   True, but we have some extra later between which does the cli command
   not usable (at least for the moment)
  
   I already know how to share the key's among all servers, that works
   fine, IPA/Apache/Kerberos only doesn't like the other hostname
   (loadbalancer), or the client doesn't understand it.
  
   So fixing this saves me really much more time than doing the another way.
 
  Kerberos is not load balancer friendly. It is something that is a known
  property of Kerberos.
  I remember MIT mentioning something that they did or might do to help
  with that so it might make sense to ask this question on the MIT
  Kerberos user list.
 
  
   Thanks!
  
   Matt
  
   2015-03-31 16:24 GMT+02:00 Petr Spacek pspa...@redhat.com:
   On 31.3.2015 16:10, Matt . wrote:
   HI Petr,
  
   We had a several of reasons why we did that. We wanted to use one
   language for that, and also have formatted returns. There was also
   some security issue which came up.
   I would be very interested in the security reason. If you see any 
   problem with
   'ipa' command or FreeIPA API please send me a private e-mail or contact
   secal...@redhat.com directly.
  
   I could ask you, why does IPA json itself ? if you see what it posts
   and what it gets back as result it makes it much more clear in
   development.
   I do not understand the question, sorry.
  
   If you want to see what 'ipa' command does run it with '-vv' parameter:
   $ ipa -vv user-find
  
   It will print JSON request and reply:
   ipa: INFO: Request: {
id: 0,
method: user_find,
params: [
[
null
],
{
all: false,
no_members: false,
pkey_only: false,
raw: false,
version: 2.115,
whoami: false
}
]
   }
   ipa: INFO: Response: {
error: null,
id: 0,
principal: admin@IPA.EXAMPLE,
result: {
count: 2,
result: [
{
dn: 
   uid=admin,cn=users,cn=accounts,dc=ipa,dc=example,
gidnumber: [
138100
],
   ...
  
  
   HTTP loadbalancing is not difficult at all, as we post to the
   webserver I need to have that part only auth right. We do more very
   specific loadbalancing stuff and this is the most easy one as it's
   only webserver forward, but IPA/Kerberos has an issue with the
   principal it seems... it cannot be hard to make that accepted I would
   say.
   If you insist on Kerberos servers behind a load balancer... you will 
   need to
   somehow share the Kerberos key among all servers. I will defer that to
   Kerberos experts here.
  
   I'm still looking for solutions :)
   Sure, but you will save a lot of time and nerves if you simply call 
   'ipa'
   command :-)
  
   Have a nice day!
  
   Petr^2 Spacek
  
   Cheers,
  
   Matt
  
   2015-03-31 15:58 GMT+02:00 Petr Spacek pspa...@redhat.com:
   On 31.3.2015 15:23, Matt . wrote:
   Hi Petr,
  
   We discussed that before indeed, but SRV is not usable in this case.
  
   My clients are just webservers (apache) doing some executes of CURL
   commands to ipa/json, actually the same commands as the webgui does
   using json, but we curl it.
  
   Do you have a better view now ?
   Yes. If you have seen the previous discussion then you know that it 
   will be
   pretty difficult to do this kind of load balancing.
  
   Why are you not using 'ipa' command or Python API we have instead? 
   Why to use
   CURL and make things more complex?
  
   Petr^2 Spacek
  
   2015-03-31 15:03 GMT+02:00 Petr Spacek pspa...@redhat.com:
   On 31.3.2015 14:35, Matt . wrote:
   Hi Petr,
  
   As this is not my topic it's for me quite simple.
  
   I need to post to /ipa/json through a loadbalancer, nothing more.
  
   i have
  
   ldap-01.domain.tld (ipa1)
   ldap-01.domain.tld (ipa2)
  
   and my loadbalancer is ldap.domain.tld
  
   ldap requests over a loadbalancer are quite simple and working, but
   the json part is more difficult because of the ticket and the dns
   name. I have added a san ldap.domain.tld to the webgui and there 
   is a
   http/ldap.domain.tld service on the ipa server.
  
   I get a nonvalid kerberos ticket when I go through ldap.domain.tld 
   to
   ldap-01.domain.tld, but when I change my script

Re: [Freeipa-users] freeipa behind a load balancer

2015-03-31 Thread Brendan Kearney

On Tue, 2015-03-31 at 13:54 -0400, Simo Sorce wrote:
 On Tue, 2015-03-31 at 13:50 -0400, Simo Sorce wrote:
  But IPA is more complex and some operations will be performed directly
  against the specific server name, so you need to keep 2 sets of keys
  (one for the server name and one for the load balancer name), but that
  does not work right now.
 
 One experiment that can be done is to remove all per-server HTTP
 services for the IPA server, and instead add their name as aliases on
 the common load-balancer name.
 
 This would mean that all IPA servers would have just one key in their
 HTTP keytab, but the KDC would release tickets readable by that key for
 any name the clients may ask for.
 
 It is a bit tricky, every time you build a replica you want to
 load-balance you'll have to go back and remove the service and switch
 keytabs, but it may be an option. Of course if you brick IPA then you
 get to keep the pieces :-)
 
 Simo.
 

careful there, as kerberos balks at CNAME records.  i think you need to
use A records.  i ran into a couple odd issues and decided to only use
A/PTR records for my stuff and never went exploring for
options/alternatives.

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

Re: [Freeipa-users] freeipa behind a load balancer

2015-03-31 Thread Brendan Kearney

On Tue, 2015-03-31 at 19:36 +0200, Matt . wrote:
 OK, but as I say, without the loadbalancer, same domain it works.
 
All the more reason to capture the session and review it in wireshark.

 My IPA server also sees the client name and ptr as I do nat.
 
 So you create a keytab for your host you are doing the commands from ?
all of my hosts get a host principal and have it put
in /etc/krb5.keytab.  i run kadmin to generate them.  freeipa likely has
utilities for this, but am not sure what they are.

 I was using a user keytab and run my commands as that user, that works
 to ipa-01
 
 It's getting something more clear.


-- 
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] Unknown Client?

2015-03-17 Thread Brendan Kearney

On Tue, 2015-03-17 at 18:07 +0100, Natxo Asenjo wrote:
 
 
 On Tue, Mar 17, 2015 at 4:19 PM, Tevfik Ceydeliler
 tevfik.ceydeli...@astron.yasar.com.tr wrote:
 Hi,
 Altough I have this configuration in client .conf:
 
 ##
 client 172.30.47.241 {
secret  = 877909
shortname   = VodafonePinarsuAPNYeni1
nastype = other
 }
 
 client 172.30.47.242 {
secret  = 877909
shortname   = VodafonePinarsuAPNYeni2
nastype = other
 }
 
 
 
 Why I get this error?
 
 
 #
 
 Tue Mar 17 14:31:55 2015 : Error: Ignoring request to
 authentication address * port 1812 from unknown client
 172.30.47.242 port 58312
 Tue Mar 17 14:32:01 2015 : Error: Ignoring request to
 authentication address * port 1812 from unknown client
 172.30.47.241 port 6040
 
 
 #
 
 
 I think you should post your question to the free*radius* mailing
 list ;-)
 
 
 --
 Groeten,
 natxo

yes, and when you do post to that list, give the output of radiusd -X.
see http://wiki.freeradius.org/guide/Troubleshooting

-- 
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] Getfedora.org ssl cert issue

2015-01-12 Thread brendan kearney

Can someone up-channel an issue with getfedora.org?  The site changed URLs,
and the cert was not amended to include the new URL as a Subject
Alternative Name and now cert mismatches are occurring.
-- 
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] Group Policy-like features in FreeIPA

2015-01-12 Thread brendan kearney

OpenAFS?
On Jan 12, 2015 11:04 AM, Craig White cwh...@skytouchtechnology.com
wrote:

  *From:* freeipa-users-boun...@redhat.com [mailto:
 freeipa-users-boun...@redhat.com] *On Behalf Of *Dale Macartney
 *Sent:* Sunday, January 11, 2015 2:16 PM
 *To:* freeipa-users@redhat.com
 *Subject:* [Freeipa-users] Group Policy-like features in FreeIPA



 Morning folks

 I am currently working on a little pet project which I think some would
 find useful.

 I would like to introduce some group policy like functionality into a
 FreeIPA domain.

 For example:

 In an environment running FreeIPA Server with Fedora or RHEL based
 workstations, I would like to be able to introduce a few extra features
 which initially may be pushed via a login script (maybe even configure a
 dbus session as well, who knows?).

 My intentions here would be to be able to apply host specific policies as
 well as have the option for user specific policies which would be applied
 when the user logs in.

 Practically speaking, adding an attribute to LDAP to specify a login
 script file name is easy enough, however actually fetching this is where I
 am hoping for a bit of brain storming. My thoughts would be the local user
 would fetch the name of the login script via ldap, and then perhaps fetch
 the file from a shared resource on the FreeIPA masters in order to be
 executed locally.

 LDAP is obviously replicated, however to my knowledge, there is no file
 synchronization between masters. I am thinking something similar to the MS
 equivalent of the SYSVOL data that replicates between MS Domain
 Controllers. One option would be to store all data within LDAP, however
 I've seen many scenarios where admins store CD ISO's in replicated domain
 data, so I am not certain this would be the best option.

 With this replicated data folder, I would be able to store centrally
 managed scripts which would be used for hosts or users, and then configure
 the default user template on each workstation (/etc/skel/) to add the login
 script file name which would be fetched from the users LDAP attributes.

  Real world usability for what I am thinking of is a way to manage users
 who can have their corporate email mailbox configured on login,
 automatically setting the users session to point to an internal SSO enabled
 proxy server or perhaps any other number of things which an admin may wish
 to achieve without the need to manually do the work themselves.

 Has anyone undertaken a similar scenario in their environments or would
 perhaps have any suggestions on how to manage the centrally accessible file
 stores?

 Many thanks
 

 Specifically, I haven’t fully implemented what you are asking but
 obviously parts and pieces yes.

 One of the best features of Linux and all of its various toolsets is that
 one are quite so overarching and the objectives are more focused. String
 them together and you have a working tool set. As a system administrator,
 you learn to pipe grep output to awk or sed or cut etc.

 SYSVOL ó NFS and if that doesn’t do it for you, check out Unison.

 I guess one of the temptations of FreeIPA is to try to make it exactly
 like active directory. The FreeIPA developers are already doing an amazing
 job without a ton of manpower.

 Craig

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

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

Re: [Freeipa-users] ipa / sudoers on centos 6.3 client

2015-01-02 Thread Brendan Kearney

On Fri, 2015-01-02 at 15:19 +, Chris Card wrote:
 I have existing machines running CentOS 6.3 which I want to include in
 a freeipa domain.
 
 The domain controller machine is running Fedora 21 and
 freeipa-server-4.1.1-2 while the latest version of ipa I can find that
 runs on CentOS 6.3 is ipa-client-3.0.0-37.el6.x86_64.
 
 
 I have successfully run ipa-client-install on the CentOS 6.3 client
 and set up users who can ssh to the client using ssh-keys.
 
 
 The problem is that I can't get sudo rules to work. I know that the
 ipa client software version 3.0.0 doesn't automatically set up all the
 configuration for sssd to control sudo access, but I have set up all
 the configuration necessary manually:
 
 
 On the client, /etc/nsswitch.conf has 
 
 
   sudoers files sss   
 
 
 /etc/sssd/sssd/conf has
 
 
 [domain/default]
 
 
 cache_credentials = True
 krb5_realm = REALM
 krb5_server = ipa server:88
 id_provider = ldap
 auth_provider = ldap
 chpass_provider = ldap
 ldap_tls_cacertdir = /etc/openldap/cacerts
 [domain/domain]
 
 
 cache_credentials = True
 krb5_store_password_if_offline = True
 ipa_domain = domain
 id_provider = ipa
 auth_provider = ipa
 access_provider = ipa
 chpass_provider = ipa
 ipa_dyndns_update = True
 ipa_server = ipa server
 ldap_tls_cacert = /etc/ipa/ca.crt
 sudo_provider = ldap
 ldap_uri = ldap://ipa server
 ldap_sudo_search_base = ou=sudoers,domain base dn
 ldap_sasl_mech = GSSAPI
 ldap_sasl_authid = host/client fqdn
 ldap_sasl_realm = REALM
 krb5_server = ipa server
 debug_level = 9
 [sssd]
 services = nss, pam, ssh, sudo
 config_file_version = 2
 
 
 domains = domain, default
 debug_level = 9
 [nss]
 debug_level = 9
 
 
 [pam]
 debug_level = 9
 
 
 [sudo]
 debug_level = 9
 [autofs]
 
 
 I have validated the ldap sasl configuration using ldapsearch, so I'm
 sure they are correct.
 
 
 The nisdomainname command returns the domain name.
 
 
 The sudo rules are:
 # ipa sudorule-find
 
 2 Sudo Rules matched
 
   Rule name: sudo-host1
   Enabled: TRUE
   Command category: all
   RunAs User category: all
   User Groups: host1-rw
   Host Groups: host1
   Sudo Option: -authenticate
 
 
   Rule name: sudo-host2
   Enabled: TRUE
   User Groups: host2-rw
   Host Groups: host2
   Sudo Option: -authenticate
 
 Number of entries returned 2
 
 
 
 When a user in user group host1-rw sshs to a client in host group
 host1 and runs sudo su - the user gets prompted for a password even
 though the sudo option -authenticate is set.
 I'm not convinced that sudo is even attempting to use sssd, but I'm
 not sure how to confirm this.
 
 
 I have seen some references to /etc/sudo-ldap.conf in online
 discussions of similar issues. This file exists on my client, but
 everything is commented out. Do I need to put the ldap client
 configuration in /etc/sudo-ldap.conf as well as /etc/sssd/sssd.conf
 for CentOS 6.3 clients?
 
 
 Any ideas about how to work out what is failing?
 
 
 Chris
 
try !authenticate (without the quotes), not  -authenticate (again,
no quotes).


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

Re: [Freeipa-users] bind-dyndb-ldap and ddns updates from dhcp

2014-12-31 Thread Brendan Kearney

On Wed, 2014-12-31 at 19:06 +0100, Jan Pazdziora wrote:
 On Mon, Dec 29, 2014 at 07:12:26PM -0500, Brendan Kearney wrote:
  On Mon, 2014-12-29 at 16:53 -0500, Dmitri Pal wrote:
   bind-dyndb-ldap isa back end driver for BIND to get data from an LDAP 
   storage.
   The updates are done by BIND. The IPA BIND accepts kerberos based updates.
   
   http://www.freeipa.org/page/FreeIPAv2:Dynamic_updates_with_GSS-TSIG
  
  this allows for a ticketed client to update DNS records directly, which
  is not a best practice and is a huge security risk.  clients should not
  be able to manipulate DNS zones.
 
 Only if you configure that. But you don't have to grant krb5-self,
 you can grant the
 
   SERVICE\047ipaserver.example@example.com wildcard * ANY;
 
 and just have the DHCP service call nsupdate -g.
 
  dynamic updates to DNS zones should come from DHCP, where dynamic
  addressing is managed.  as such, i have directives in DHCP and DNS to
  establish authenticated updates between DHCP and DNS.  for example:
  
  /etc/named.conf:
  
  key dhcp {
  algorithm hmac-md5;
  secret SomeRandomString;
  };
 
 With FreeIPA, Kerberos authentication is really the preferred way
 of integrating pieces together because it provides the identity of
 the service running the action, not just some shared secret / password.
 
  because the DHCP daemon is not kerberized, the update policies do not
 
 [...]
 
  i am wondering how to manage DDNS updates from DHCP, where kerberized
  updates are not likely going to happen.
 
 What DHCP software is that and how hard would it be to Kerberize it?
 

i have played with nsupdate, and it does look like updates will be
allowed if i remove the access restriction, but i am losing the
authenticity of the update, since the TSIG shared secret signs the
update.

regardless of authentication, client updates to DNS zones are still a
risk and a rogue app or user can still perform direct updates to zones,
leading to impersonation/interception of services, denial of service
attacks and more.  endpoints, or their users, should not be trusted to
make updates to DNS zones.  TSIG signed updates from servers are still
preferred over authenticated updates from endpoints or users.

i am using ISC DHCP, and cannot speak to any level of effort required to
incorporate Kerberos into the code.

-- 
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] bind-dyndb-ldap and ddns updates from dhcp

2014-12-29 Thread Brendan Kearney

where can i find howto info around setting up bind-dyndb-ldap to accept
ddns updates from dhcp?  usually, i have a shared key defined in dns and
dhcp, and the updates are authenticated.  where are the docs for setting
this up in bind-dyndb-ldap?

-- 
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] Fedora Core IPTables or FirewallID?

2014-08-26 Thread brendan kearney

systemctl stop firewalld
systemctl disable firewalld

systemctl stop iptables
systemctl disable iptables

sudo iptables -nvL

This is not a recommended config, as a firewall will save your bacon
without you realizing it.  Fwbuilder is a great package in the fedora repos
that will write excellent firewall policies.  Maybe take a look at that.
On Aug 25, 2014 10:24 PM, Chris Whittle cwhi...@gmail.com wrote:

 I've got my server up and running great with one exception every time I
 reboot I have to login and flush the iptables or nothing can connect.

 I've found a ton of fixes and none seem to work, I'm on FC20 does anyone
 have experience with it and wouldn't mind helping?

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

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

Re: [Freeipa-users] FreeIPA and FQDN requirements

2014-08-08 Thread brendan kearney

Kerberos is dependent on A records in dns.  The instance (as in
principal/instance@REALM) should match the A record in dns.

There is absolutely no Kerberos dependency on hostnames being fully
qualified.  I have all my devices named with short names and I have no
issues with Kerberos ticketing.

This seems to be an artificial requirement in FreeIPA that is wrong.
On Aug 8, 2014 8:54 AM, Bruno Henrique Barbosa 
bruno-barb...@prodesan.com.br wrote:

 Hello everyone,

 I'm running through an issue where an application needs its server's
 hostname to be in short name format, such as server and not 
 server.example.com. When I started deploying FreeIPA in the very
 beginning of this year, I remember I couldn't install freeipa-client with a
 bare ipa-client install, because of this:

 

 [root@server ~]# hostname
 server
 [root@server ~]# hostname -f
 server.example.com
 [root@server ~]# ipa-client-install
 Discovery was successful!
 Hostname: server.example.com
 Realm: EXAMPLE.COM
 DNS Domain: example.com
 IPA Server: ipa01.example.com
 Base DN: dc=example,dc=com

 Continue to configure the system with these values? [no] yes
 User authorized to enroll computers: admin
 Synchronizing time with KDC...
 Unable to sync time with IPA NTP Server, assuming the time is in sync.
 Please check that port 123 UDP is opened.
 Password for ad...@example.com:
 Joining realm failed: The hostname must be fully-qualified: server
 Installation failed. Rolling back changes.
 IPA client is not configured on this system.

 

 So, using the short name as hostname didn't work for install, I then make
 it like ipa-client install --hostname=`hostname -f` --mkhomedir -N, and
 it installs and works like a charm, BUT it updates the machine's hostname
 to FQDN.

 What I tested and, at first, worked: after deploying and ipa-client
 installation with those parameters which work, renaming the machine back to
 a short name AT FIRST is not causing any problems. I can login with my ssh
 rules perfectly, but I don't find any IPA technical docs saying it
 will/won't work if I change the hostname back to short name and not FQDN.

 Searching for it, I found on RedHat guide: The hostname of a system is
 critical for the correct operation of Kerberos and SSL. Both of these
 security mechanisms rely on the hostname to ensure that communication is
 occurring between the specified hosts.
 I've also found this message
 http://osdir.com/ml/freeipa-users/2012-03/msg6.html which seems to be
 related to my case, but what I need to know is: where does it state FQDN is
 a mandatory requirement in order to FreeIPA to work and/or is there
 anything else (a patch, update, whatever) to solve this issue, so I don't
 need to change my applications?

 Thank you and sorry for the wall of a text.

 PS: Enviroment is CentOS 6.5, in both IPA server and client. DNS is not
 the same server as IPA (it forwards to a Windows DC).

 RPMs:
 libipa_hbac-1.9.2-129.el6_5.4.x86_64
 libipa_hbac-python-1.9.2-129.el6_5.4.x86_64
 python-iniparse-0.3.1-2.1.el6.noarch
 ipa-pki-common-theme-9.0.3-7.el6.noarch
 ipa-pki-ca-theme-9.0.3-7.el6.noarch
 ipa-admintools-3.0.0-37.el6.x86_64
 ipa-server-selinux-3.0.0-37.el6.x86_64
 ipa-server-3.0.0-37.el6.x86_64
 ipa-python-3.0.0-37.el6.x86_64
 ipa-client-3.0.0-37.el6.x86_64



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

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

Re: [Freeipa-users] FreeIPA and FQDN requirements

2014-08-08 Thread brendan kearney

Correction, its primary/instance@REALM
On Aug 8, 2014 10:57 AM, brendan kearney bpk...@gmail.com wrote:

 Kerberos is dependent on A records in dns.  The instance (as in
 principal/instance@REALM) should match the A record in dns.

 There is absolutely no Kerberos dependency on hostnames being fully
 qualified.  I have all my devices named with short names and I have no
 issues with Kerberos ticketing.

 This seems to be an artificial requirement in FreeIPA that is wrong.
 On Aug 8, 2014 8:54 AM, Bruno Henrique Barbosa 
 bruno-barb...@prodesan.com.br wrote:

 Hello everyone,

 I'm running through an issue where an application needs its server's
 hostname to be in short name format, such as server and not 
 server.example.com. When I started deploying FreeIPA in the very
 beginning of this year, I remember I couldn't install freeipa-client with a
 bare ipa-client install, because of this:

 

 [root@server ~]# hostname
 server
 [root@server ~]# hostname -f
 server.example.com
 [root@server ~]# ipa-client-install
 Discovery was successful!
 Hostname: server.example.com
 Realm: EXAMPLE.COM
 DNS Domain: example.com
 IPA Server: ipa01.example.com
 Base DN: dc=example,dc=com

 Continue to configure the system with these values? [no] yes
 User authorized to enroll computers: admin
 Synchronizing time with KDC...
 Unable to sync time with IPA NTP Server, assuming the time is in sync.
 Please check that port 123 UDP is opened.
 Password for ad...@example.com:
 Joining realm failed: The hostname must be fully-qualified: server
 Installation failed. Rolling back changes.
 IPA client is not configured on this system.

 

 So, using the short name as hostname didn't work for install, I then make
 it like ipa-client install --hostname=`hostname -f` --mkhomedir -N, and
 it installs and works like a charm, BUT it updates the machine's hostname
 to FQDN.

 What I tested and, at first, worked: after deploying and ipa-client
 installation with those parameters which work, renaming the machine back to
 a short name AT FIRST is not causing any problems. I can login with my ssh
 rules perfectly, but I don't find any IPA technical docs saying it
 will/won't work if I change the hostname back to short name and not FQDN.

 Searching for it, I found on RedHat guide: The hostname of a system is
 critical for the correct operation of Kerberos and SSL. Both of these
 security mechanisms rely on the hostname to ensure that communication is
 occurring between the specified hosts.
 I've also found this message
 http://osdir.com/ml/freeipa-users/2012-03/msg6.html which seems to
 be related to my case, but what I need to know is: where does it state FQDN
 is a mandatory requirement in order to FreeIPA to work and/or is there
 anything else (a patch, update, whatever) to solve this issue, so I don't
 need to change my applications?

 Thank you and sorry for the wall of a text.

 PS: Enviroment is CentOS 6.5, in both IPA server and client. DNS is not
 the same server as IPA (it forwards to a Windows DC).

 RPMs:
 libipa_hbac-1.9.2-129.el6_5.4.x86_64
 libipa_hbac-python-1.9.2-129.el6_5.4.x86_64
 python-iniparse-0.3.1-2.1.el6.noarch
 ipa-pki-common-theme-9.0.3-7.el6.noarch
 ipa-pki-ca-theme-9.0.3-7.el6.noarch
 ipa-admintools-3.0.0-37.el6.x86_64
 ipa-server-selinux-3.0.0-37.el6.x86_64
 ipa-server-3.0.0-37.el6.x86_64
 ipa-python-3.0.0-37.el6.x86_64
 ipa-client-3.0.0-37.el6.x86_64



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


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

Re: [Freeipa-users] FreeIPA and FQDN requirements

2014-08-08 Thread brendan kearney

Arent all of those lookups done in dns?  Wouldnt that mean hostnames being
fqdn's is irrelevant?
On Aug 8, 2014 12:11 PM, Rich Megginson rmegg...@redhat.com wrote:

  On 08/08/2014 08:57 AM, brendan kearney wrote:

 Kerberos is dependent on A records in dns.  The instance (as in
 principal/instance@REALM) should match the A record in dns.

 There is absolutely no Kerberos dependency on hostnames being fully
 qualified.  I have all my devices named with short names and I have no
 issues with Kerberos ticketing.

 This seems to be an artificial requirement in FreeIPA that is wrong.


 The other hostname requirement is for TLS/SSL, for MITM checking.  By
 default, when an SSL server cert is issued, the subject DN contains cn=fqdn
 as the leftmost component.  clients use this fqdn to verify the server.
 That is, client knows the IP address of the server - client does a reverse
 lookup (i.e. PTR) to see if the server returned by that lookup matches the
 cn=fqdn in the server cert.  This requires reverse lookups are configured
 and that the fqdn is the first name/alias returned.

  On Aug 8, 2014 8:54 AM, Bruno Henrique Barbosa 
 bruno-barb...@prodesan.com.br wrote:

  Hello everyone,

 I'm running through an issue where an application needs its server's
 hostname to be in short name format, such as server and not 
 server.example.com. When I started deploying FreeIPA in the very
 beginning of this year, I remember I couldn't install freeipa-client with a
 bare ipa-client install, because of this:

 

 [root@server ~]# hostname
 server
 [root@server ~]# hostname -f
 server.example.com
 [root@server ~]# ipa-client-install
 Discovery was successful!
 Hostname: server.example.com
 Realm: EXAMPLE.COM
 DNS Domain: example.com
 IPA Server: ipa01.example.com
 Base DN: dc=example,dc=com

 Continue to configure the system with these values? [no] yes
 User authorized to enroll computers: admin
 Synchronizing time with KDC...
 Unable to sync time with IPA NTP Server, assuming the time is in sync.
 Please check that port 123 UDP is opened.
 Password for ad...@example.com:
 Joining realm failed: The hostname must be fully-qualified: server
 Installation failed. Rolling back changes.
 IPA client is not configured on this system.

 

 So, using the short name as hostname didn't work for install, I then make
 it like ipa-client install --hostname=`hostname -f` --mkhomedir -N, and
 it installs and works like a charm, BUT it updates the machine's hostname
 to FQDN.

 What I tested and, at first, worked: after deploying and ipa-client
 installation with those parameters which work, renaming the machine back to
 a short name AT FIRST is not causing any problems. I can login with my ssh
 rules perfectly, but I don't find any IPA technical docs saying it
 will/won't work if I change the hostname back to short name and not FQDN.

 Searching for it, I found on RedHat guide: The hostname of a system is
 critical for the correct operation of Kerberos and SSL. Both of these
 security mechanisms rely on the hostname to ensure that communication is
 occurring between the specified hosts.
 I've also found this message
 http://osdir.com/ml/freeipa-users/2012-03/msg6.html which seems to
 be related to my case, but what I need to know is: where does it state FQDN
 is a mandatory requirement in order to FreeIPA to work and/or is there
 anything else (a patch, update, whatever) to solve this issue, so I don't
 need to change my applications?

 Thank you and sorry for the wall of a text.

 PS: Enviroment is CentOS 6.5, in both IPA server and client. DNS is not
 the same server as IPA (it forwards to a Windows DC).

 RPMs:
 libipa_hbac-1.9.2-129.el6_5.4.x86_64
 libipa_hbac-python-1.9.2-129.el6_5.4.x86_64
 python-iniparse-0.3.1-2.1.el6.noarch
 ipa-pki-common-theme-9.0.3-7.el6.noarch
 ipa-pki-ca-theme-9.0.3-7.el6.noarch
 ipa-admintools-3.0.0-37.el6.x86_64
 ipa-server-selinux-3.0.0-37.el6.x86_64
 ipa-server-3.0.0-37.el6.x86_64
 ipa-python-3.0.0-37.el6.x86_64
 ipa-client-3.0.0-37.el6.x86_64



 --
 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] FreeIPA and FQDN requirements

2014-08-08 Thread brendan kearney

The cert should have the fqdn, just like the kerberos instance, but the
hostname is not required to be fq'd.  The lookup of a short name, as well
as and more specifically the IP, in dns will result in the fqdn being
returned by dns (the short name resolution being affected by domain and
search directives in resolv.conf and the origin directive in dns if either
of those are absent).

Back to the point, dns lookup for cert matching is not dependent on
hostnames.  PTR lookups will always return fqdns, so a dependency on fqdns
as hostnames is artificial,  no?
On Aug 8, 2014 1:03 PM, Rich Megginson rmegg...@redhat.com wrote:

  On 08/08/2014 10:56 AM, brendan kearney wrote:

 Arent all of those lookups done in dns?


 Yes.

  Wouldnt that mean hostnames being fqdn's is irrelevant?


 Not sure what you mean.

 I guess if you issued your server certs with a subject DN of
 cn=hostname, instead of cn=hostname.domain.tld, and you had the DNS PTR
 lookups configured so that w.x.y.z returned hostname instead of
 hostname.domain.tld, then TLS/SSL would work.

  On Aug 8, 2014 12:11 PM, Rich Megginson rmegg...@redhat.com wrote:

  On 08/08/2014 08:57 AM, brendan kearney wrote:

 Kerberos is dependent on A records in dns.  The instance (as in
 principal/instance@REALM) should match the A record in dns.

 There is absolutely no Kerberos dependency on hostnames being fully
 qualified.  I have all my devices named with short names and I have no
 issues with Kerberos ticketing.

 This seems to be an artificial requirement in FreeIPA that is wrong.


 The other hostname requirement is for TLS/SSL, for MITM checking.  By
 default, when an SSL server cert is issued, the subject DN contains cn=fqdn
 as the leftmost component.  clients use this fqdn to verify the server.
 That is, client knows the IP address of the server - client does a reverse
 lookup (i.e. PTR) to see if the server returned by that lookup matches the
 cn=fqdn in the server cert.  This requires reverse lookups are configured
 and that the fqdn is the first name/alias returned.

  On Aug 8, 2014 8:54 AM, Bruno Henrique Barbosa 
 bruno-barb...@prodesan.com.br wrote:

  Hello everyone,

 I'm running through an issue where an application needs its server's
 hostname to be in short name format, such as server and not 
 server.example.com. When I started deploying FreeIPA in the very
 beginning of this year, I remember I couldn't install freeipa-client with a
 bare ipa-client install, because of this:

 

 [root@server ~]# hostname
 server
 [root@server ~]# hostname -f
 server.example.com
 [root@server ~]# ipa-client-install
 Discovery was successful!
 Hostname: server.example.com
 Realm: EXAMPLE.COM
 DNS Domain: example.com
 IPA Server: ipa01.example.com
 Base DN: dc=example,dc=com

 Continue to configure the system with these values? [no] yes
 User authorized to enroll computers: admin
 Synchronizing time with KDC...
 Unable to sync time with IPA NTP Server, assuming the time is in sync.
 Please check that port 123 UDP is opened.
 Password for ad...@example.com:
 Joining realm failed: The hostname must be fully-qualified: server
 Installation failed. Rolling back changes.
 IPA client is not configured on this system.

 

 So, using the short name as hostname didn't work for install, I then
 make it like ipa-client install --hostname=`hostname -f` --mkhomedir -N,
 and it installs and works like a charm, BUT it updates the machine's
 hostname to FQDN.

 What I tested and, at first, worked: after deploying and ipa-client
 installation with those parameters which work, renaming the machine back to
 a short name AT FIRST is not causing any problems. I can login with my ssh
 rules perfectly, but I don't find any IPA technical docs saying it
 will/won't work if I change the hostname back to short name and not FQDN.

 Searching for it, I found on RedHat guide: The hostname of a system is
 critical for the correct operation of Kerberos and SSL. Both of these
 security mechanisms rely on the hostname to ensure that communication is
 occurring between the specified hosts.
 I've also found this message
 http://osdir.com/ml/freeipa-users/2012-03/msg6.html which seems to
 be related to my case, but what I need to know is: where does it state FQDN
 is a mandatory requirement in order to FreeIPA to work and/or is there
 anything else (a patch, update, whatever) to solve this issue, so I don't
 need to change my applications?

 Thank you and sorry for the wall of a text.

 PS: Enviroment is CentOS 6.5, in both IPA server and client. DNS is not
 the same server as IPA (it forwards to a Windows DC).

 RPMs:
 libipa_hbac-1.9.2-129.el6_5.4.x86_64
 libipa_hbac-python-1.9.2-129.el6_5.4.x86_64
 python-iniparse-0.3.1-2.1.el6.noarch
 ipa-pki-common-theme-9.0.3-7.el6.noarch
 ipa-pki-ca-theme-9.0.3-7.el6.noarch
 ipa-admintools-3.0.0-37.el6.x86_64
 ipa-server-selinux-3.0.0-37.el6.x86_64
 ipa-server-3.0.0-37.el6.x86_64
 ipa-python-3.0.0-37.el6.x86_64
 ipa-client

Re: [Freeipa-users] FreeIPA and FQDN requirements

2014-08-08 Thread brendan kearney

Double check your example.  -h means the hostname of the ldap server to
connect to and issue your query to.  Man page calls it ldaphost.

I have not run across a client that does cert validation using ldap.  Is
that IPA specific?

It seems that a lot of effort is being spent to justify a dependency on
fully qualified hostnames, when there is no reason to require it.  In fact,
it may even break somethings or even violate some rfc.
On Aug 8, 2014 1:43 PM, Rich Megginson rmegg...@redhat.com wrote:

  On 08/08/2014 11:17 AM, brendan kearney wrote:

 The cert should have the fqdn, just like the kerberos instance, but the
 hostname is not required to be fq'd.  The lookup of a short name, as well
 as and more specifically the IP, in dns will result in the fqdn being
 returned by dns (the short name resolution being affected by domain and
 search directives in resolv.conf and the origin directive in dns if either
 of those are absent).

 Back to the point, dns lookup for cert matching is not dependent on
 hostnames.  PTR lookups will always return fqdns, so a dependency on fqdns
 as hostnames is artificial,  no?


 Most clients will also do the additional step of matching the hostname in
 the cert against the originally given hostname.  For example, with
 ldapsearch:

 ldapsearch -xLLLZZ -h hostname ...

 This will fail if the server cert for hostname has cn=hostname.domain.tld

  On Aug 8, 2014 1:03 PM, Rich Megginson rmegg...@redhat.com wrote:

  On 08/08/2014 10:56 AM, brendan kearney wrote:

 Arent all of those lookups done in dns?


 Yes.

  Wouldnt that mean hostnames being fqdn's is irrelevant?


 Not sure what you mean.

 I guess if you issued your server certs with a subject DN of
 cn=hostname, instead of cn=hostname.domain.tld, and you had the DNS PTR
 lookups configured so that w.x.y.z returned hostname instead of
 hostname.domain.tld, then TLS/SSL would work.

  On Aug 8, 2014 12:11 PM, Rich Megginson rmegg...@redhat.com wrote:

  On 08/08/2014 08:57 AM, brendan kearney wrote:

 Kerberos is dependent on A records in dns.  The instance (as in
 principal/instance@REALM) should match the A record in dns.

 There is absolutely no Kerberos dependency on hostnames being fully
 qualified.  I have all my devices named with short names and I have no
 issues with Kerberos ticketing.

 This seems to be an artificial requirement in FreeIPA that is wrong.


 The other hostname requirement is for TLS/SSL, for MITM checking.  By
 default, when an SSL server cert is issued, the subject DN contains cn=fqdn
 as the leftmost component.  clients use this fqdn to verify the server.
 That is, client knows the IP address of the server - client does a reverse
 lookup (i.e. PTR) to see if the server returned by that lookup matches the
 cn=fqdn in the server cert.  This requires reverse lookups are configured
 and that the fqdn is the first name/alias returned.

  On Aug 8, 2014 8:54 AM, Bruno Henrique Barbosa 
 bruno-barb...@prodesan.com.br wrote:

  Hello everyone,

 I'm running through an issue where an application needs its server's
 hostname to be in short name format, such as server and not 
 server.example.com. When I started deploying FreeIPA in the very
 beginning of this year, I remember I couldn't install freeipa-client with a
 bare ipa-client install, because of this:

 

 [root@server ~]# hostname
 server
 [root@server ~]# hostname -f
 server.example.com
 [root@server ~]# ipa-client-install
 Discovery was successful!
 Hostname: server.example.com
 Realm: EXAMPLE.COM
 DNS Domain: example.com
 IPA Server: ipa01.example.com
 Base DN: dc=example,dc=com

 Continue to configure the system with these values? [no] yes
 User authorized to enroll computers: admin
 Synchronizing time with KDC...
 Unable to sync time with IPA NTP Server, assuming the time is in sync.
 Please check that port 123 UDP is opened.
 Password for ad...@example.com:
 Joining realm failed: The hostname must be fully-qualified: server
 Installation failed. Rolling back changes.
 IPA client is not configured on this system.

 

 So, using the short name as hostname didn't work for install, I then
 make it like ipa-client install --hostname=`hostname -f` --mkhomedir -N,
 and it installs and works like a charm, BUT it updates the machine's
 hostname to FQDN.

 What I tested and, at first, worked: after deploying and ipa-client
 installation with those parameters which work, renaming the machine back to
 a short name AT FIRST is not causing any problems. I can login with my ssh
 rules perfectly, but I don't find any IPA technical docs saying it
 will/won't work if I change the hostname back to short name and not FQDN.

 Searching for it, I found on RedHat guide: The hostname of a system is
 critical for the correct operation of Kerberos and SSL. Both of these
 security mechanisms rely on the hostname to ensure that communication is
 occurring between the specified hosts.
 I've also found this message
 http://osdir.com/ml/freeipa

Re: [Freeipa-users] FreeIPA and FQDN requirements

2014-08-08 Thread brendan kearney

Maybe I am reading too far into rfc 1178, but I hardly think making
hostnames required to be fqdns is in anybodys interest.  It is not a
requirement now in any other technology anywhere, so what is the impetus to
push it?  I dont see any value in it
On Aug 8, 2014 2:37 PM, Rich Megginson rmegg...@redhat.com wrote:

  On 08/08/2014 12:21 PM, brendan kearney wrote:

 Double check your example.  -h means the hostname of the ldap server to
 connect to and issue your query to.  Man page calls it ldaphost.


 Yes.

  I have not run across a client that does cert validation using ldap.  Is
 that IPA specific?


 I'm not talking about cert validation using ldap.  I'm talking about the
 fact that, by default, the ldapsearch client will expect the hostname you
 pass in to match the hostname in the ssl server cert subject DN.

  It seems that a lot of effort is being spent to justify a dependency on
 fully qualified hostnames, when there is no reason to require it.  In fact,
 it may even break somethings or even violate some rfc.


 If requiring fully qualified hostnames violates RFCs or other standards,
 I'd like to hear about it.

  On Aug 8, 2014 1:43 PM, Rich Megginson rmegg...@redhat.com wrote:

  On 08/08/2014 11:17 AM, brendan kearney wrote:

 The cert should have the fqdn, just like the kerberos instance, but the
 hostname is not required to be fq'd.  The lookup of a short name, as well
 as and more specifically the IP, in dns will result in the fqdn being
 returned by dns (the short name resolution being affected by domain and
 search directives in resolv.conf and the origin directive in dns if either
 of those are absent).

 Back to the point, dns lookup for cert matching is not dependent on
 hostnames.  PTR lookups will always return fqdns, so a dependency on fqdns
 as hostnames is artificial,  no?


 Most clients will also do the additional step of matching the hostname in
 the cert against the originally given hostname.  For example, with
 ldapsearch:

 ldapsearch -xLLLZZ -h hostname ...

 This will fail if the server cert for hostname has
 cn=hostname.domain.tld

  On Aug 8, 2014 1:03 PM, Rich Megginson rmegg...@redhat.com wrote:

  On 08/08/2014 10:56 AM, brendan kearney wrote:

 Arent all of those lookups done in dns?


 Yes.

  Wouldnt that mean hostnames being fqdn's is irrelevant?


 Not sure what you mean.

 I guess if you issued your server certs with a subject DN of
 cn=hostname, instead of cn=hostname.domain.tld, and you had the DNS PTR
 lookups configured so that w.x.y.z returned hostname instead of
 hostname.domain.tld, then TLS/SSL would work.

  On Aug 8, 2014 12:11 PM, Rich Megginson rmegg...@redhat.com wrote:

  On 08/08/2014 08:57 AM, brendan kearney wrote:

 Kerberos is dependent on A records in dns.  The instance (as in
 principal/instance@REALM) should match the A record in dns.

 There is absolutely no Kerberos dependency on hostnames being fully
 qualified.  I have all my devices named with short names and I have no
 issues with Kerberos ticketing.

 This seems to be an artificial requirement in FreeIPA that is wrong.


 The other hostname requirement is for TLS/SSL, for MITM checking.  By
 default, when an SSL server cert is issued, the subject DN contains cn=fqdn
 as the leftmost component.  clients use this fqdn to verify the server.
 That is, client knows the IP address of the server - client does a reverse
 lookup (i.e. PTR) to see if the server returned by that lookup matches the
 cn=fqdn in the server cert.  This requires reverse lookups are configured
 and that the fqdn is the first name/alias returned.

  On Aug 8, 2014 8:54 AM, Bruno Henrique Barbosa 
 bruno-barb...@prodesan.com.br wrote:

  Hello everyone,

 I'm running through an issue where an application needs its server's
 hostname to be in short name format, such as server and not 
 server.example.com. When I started deploying FreeIPA in the very
 beginning of this year, I remember I couldn't install freeipa-client with 
 a
 bare ipa-client install, because of this:

 

 [root@server ~]# hostname
 server
 [root@server ~]# hostname -f
 server.example.com
 [root@server ~]# ipa-client-install
 Discovery was successful!
 Hostname: server.example.com
 Realm: EXAMPLE.COM
 DNS Domain: example.com
 IPA Server: ipa01.example.com
 Base DN: dc=example,dc=com

 Continue to configure the system with these values? [no] yes
 User authorized to enroll computers: admin
 Synchronizing time with KDC...
 Unable to sync time with IPA NTP Server, assuming the time is in sync.
 Please check that port 123 UDP is opened.
 Password for ad...@example.com:
 Joining realm failed: The hostname must be fully-qualified: server
 Installation failed. Rolling back changes.
 IPA client is not configured on this system.

 

 So, using the short name as hostname didn't work for install, I then
 make it like ipa-client install --hostname=`hostname -f` --mkhomedir -N,
 and it installs and works like a charm, BUT it updates

Re: [Freeipa-users] Setting up IPA to log remotely

2014-06-02 Thread Brendan Kearney

On Tue, 2014-06-03 at 00:42 +, Steven Jones wrote:
 Hi,
 
 I'll raise a request for this to be added then.
 
 Its a bit of an enterprise requirement feature that is of use for us.
 
 Not having much luck with rsyslog and application logs at the moment, good 
 and accurate docs seem lacking for RHEL6.
 
 regards
 
 Steven 
 
 From: Rob Crittenden rcrit...@redhat.com
 Sent: Tuesday, 3 June 2014 9:27 a.m.
 To: Steven Jones
 Cc: freeipa-users@redhat.com
 Subject: Re: [Freeipa-users] Setting up IPA to log remotely
 
 Steven Jones wrote:
  Is there a way to get IPA to send its logs remotely?
 
 We intend to do something like this with audit, most likely using the
 systemd journal, but it's a ways off.
 
 For now you'd need to do it manually on a per-service basis. I'd suggest
 looking at rsyslogd. You should be able to at least get the Apache and
 389-ds logs using that.
 
 rob
 
 
 
 ___
 Freeipa-users mailing list
 Freeipa-users@redhat.com
 https://www.redhat.com/mailman/listinfo/freeipa-users

check out http://www.rsyslog.com/doc/master/index.html for good and
accurate docs.  i am using fedora 16 and 20 with RELP, fowarding syslog
from everywhere to a central location, and then dumping the logs into
mysql.  phplogcon bolts on top of it for a web view of all the logs.

on a sending source:
$ModLoad imuxsock # provides support for local system logging (e.g. via
logger command)
$SystemLogRateLimitInterval 0
$IMUXSockRateLimitInterval 0

$ModLoad imklog   # provides kernel logging support (previously done by
rklogd)
#$ModLoad immark  # provides --MARK-- message capability

# Provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

# Provides TCP syslog reception
$ModLoad imtcp
$InputTCPServerRun 514

# Provides RELP transmission 
$ModLoad omrelp
*.* :omrelp:192.168.25.1:20514;RSYSLOG_ForwardFormat
~

on a receiving destination:
$ModLoad imuxsock # provides support for local system logging (e.g. via
logger command)
$SystemLogRateLimitInterval 0
$IMUXSockRateLimitInterval 0

$ModLoad imklog   # provides kernel logging support (previously done by
rklogd)
#$ModLoad immark  # provides --MARK-- message capability

# Provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

# Provides TCP syslog reception
$ModLoad imtcp
$InputTCPServerRun 514

# Provides RELP reception
$ModLoad imrelp
$InputRELPServerRun 20514

# Provides MySQL connectivity
$ModLoad ommysql
# MASSIVE INSERT RATE FOR DB / SCALED DB LOGGING
$WorkDirectory /var/spool/rsyslog # default location for work (spool)
files
$ActionQueueType LinkedList # use asynchronous processing
$ActionQueueFileName dbq# set file name, also enables disk mode
$ActionResumeRetryCount -1  # infinite retries on insert failure
# for PostgreSQL replace :ommysql: by :ompgsql: below:
*.* :ommysql:server.domain.tld,Syslog,user,password


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

[Freeipa-users] using keytabs for auth to ldap

2014-04-01 Thread Brendan Kearney

What distribution you use? Fedora
Which distribution version you use? Fedora 20, with latest updates
Which architecture you use? x86_64 on a qemu VM

What plugin version you use? bind-dyndb-ldap-4.1-1.fc20.x86_64
Do you use bind-dyndb-ldap as part of FreeIPA installation? no, using
openldap-servers-2.4.39-2.fc20.x86_64
Which version of BIND you use? bind-9.9.4-12.P2.fc20.x86_64

Please provide dynamic-db section from configuration
file /etc/named.conf
dynamic-db bpk2.com {
library ldap.so;
arg uri ldap://127.0.0.1/;;
arg base cn=dns,dc=bpk2,dc=com;
arg auth_method simple;
arg bind_dn cn=Manager,dc=bpk2,dc=com;
arg password ***REMOVED***;
arg sync_ptr yes;
arg dyn_update yes;
arg connections 2;
arg verbose_checks yes;
};

Do you have some other text based or DLZ zones configured? no
Do you have some global forwarders configured in BIND configuration
file? no

Do you have some settings in global configuration object in LDAP?
dn: cn=dns,dc=my-domain,dc=com
cn: dns
idnspersistentsearch: FALSE
idnszonerefresh: 30
objectclass: top
objectclass: nsContainer
objectclass: idnsConfigObject

i want to use bind-dyndb-ldap with keytabs against my directory.  i have
created the principal DNS/test.bpk2@bpk2.com, and can have created
the keytab file.  what i want to know is:

what ldap object should i create to match up against the kerberos
principal?
i have to grant access to the ldap tree, so what ID will be presented to
ldap when using the keytab?
am i able to use the sasl_username without the sasl_password to
establish that?
being that i want to use a keytab, the username would be in there,
correct?
when i list the keys in the keytab, there is a PRIMARY, an INSTANCE and
a REALM (DNS/test.bpk2@bpk2.com).  is the PRIMARY (DNS) or the
INSTANCE (test.bpk2.com) what has to be linked in ldap to the kerberos
identity?
do i need a specific olcAuthzRegexp to massage the kerberos ID into a
proper ldap DN, like i am doing already for my ID?  example:
{0}uid=([^,]*),cn=bpk2.com,cn=gssapi,cn=auth uid=
$1,ou=Users,dc=bpk2,dc=com
i am running n-way multi master ldap.  does the uri directive support
more than one value (ldap://ldap1.bpk2.com ldap://ldap2.bpk2.com)?
can the SRV records be used to point the uri directive at the ldap
servers by querying for them?  ha, thats a-chicken-and-the-egg topic,
but an interesting one...

i am assuming my named.conf will change to include:

arg uri ldap://ldap1.bpk2.com/ ldap://ldap2.bpk2.com;;
arg auth_method sasl;
arg sasl_mech GSSAPI;
arg krb5_keytab FILE:/etc/named.keytab;

is there anything else obvious that i am missing?

thank you,

brendan

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

Re: [Freeipa-users] bind-dyndb-ldap: using keytabs for auth to ldap

2014-04-01 Thread Brendan Kearney

 Hello!
 Before I dive into details, please read about the following bug:
 https://fedorahosted.org/bind-dyndb-ldap/ticket/134
 
 I just found it, fixed it and I'm attaching patch for you so you don't need 
 to 
 wait for a new release :-)
thanks, but i am not sure how to apply patches.


 Your LDAP server will get the whole principal and it is up to the server how 
 it will map it to some existing entity.
what do you do on the IPA side?  did you follow some best practice?  i
am trying not to reinvent the wheel.

 BTW documentation about named.conf syntax is in README:
 https://git.fedorahosted.org/cgit/bind-dyndb-ldap.git/plain/README
as well as in the package.  i did consult the doc.

 Let us know if you encounter any problem.
certainly will.

 BTW did you see FreeIPA project? It integrates LDAP+Kerberos with management 
 tools and nice user interface and solver Microsoft AD integration.
 
 Maybe it could save you some headaches ...
not a big fan of 389, as it is a fork of openldap, though RH has done
some nifty things with it (dogtag, IPA, etc).  i am a bit of a purist,
thats all.  also, this is a learning exercise for me.  i am trying to
understand the inner workings of each of the pieces and see how they
interoperate with each other.

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

Re: [Freeipa-users] bind-dyndb-ldap: using keytabs for auth to ldap

2014-04-01 Thread Brendan Kearney

 No, it is not.
 http://port389.org/wiki/History

ok then.  still, i am trying to learn the individual pieces and get them
working together.

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

Re: [Freeipa-users] bind-dyndb-ldap 4.1 upgrade

2014-03-04 Thread Brendan Kearney

On Tue, 2014-03-04 at 14:11 +0100, Petr Spacek wrote:
 Hello,
 
 On 3.3.2014 22:57, Brendan Kearney wrote:
   Which distribution version you use? Fedora 20, with latest updates
   What plugin version you use? bind-dyndb-ldap-3.5-1.fc20.x86_64
 
 Please make sure that you read and follow
 https://www.redhat.com/archives/freeipa-interest/2014-February/msg1.html
 before you upgrade bind-dyndb-ldap to version 4.x.
 
 The bind-dyndb-ldap 4.1 is being pushed to Fedora-updates repo right now.
 
 I will comment on your configuration in-line:
  Do you use bind-dyndb-ldap as part of FreeIPA installation? no, using
  openldap-servers-2.4.39-2.fc20.x86_64
 Please make sure that syncrepl provider is configured on your LDAP server. 
 Syncrepl support on server side is *required* from version 4.0.
 
  Please provide dynamic-db section from configuration
  file /etc/named.conf
  dynamic-db my-domain.com {
   library ldap.so;
arg uri ldap://127.0.0.1/;;
   arg base cn=dns,dc=my-domain,dc=com;
arg auth_method simple;
   arg bind_dn cn=Manager,dc=my-domain,dc=com;
   arg password *;
   arg psearch no;
 This option was removed (replaced by mandatory syncrepl).
 
   // arg serial_autoincrement yes;
 This feature is now mandatory so the option was removed. Please make sure 
 that 
 bind-dyndb-ldap has write access to the configured sub-tree.
 
   arg sync_ptr yes;
   arg dyn_update yes;
   arg connections 2;
arg cache_ttl 300;
 This option was removed (replaced by mandatory syncrepl).
 
   arg verbose_checks yes;
  };
 
 I hope this helps to prevent surprise after upgrade.
 
 Let us know if you encounter any problems!
 

syncrepl is configured and i am using it for N-Way Multi Master
Replication between 2 hosts.  are there specific configs i need to
add/change for the bind-dyndb-ldap piece?

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

Re: [Freeipa-users] best practices for subdomains

2014-03-03 Thread Brendan Kearney

On Mon, 2014-03-03 at 09:33 +0100, Petr Spacek wrote:
 On 1.3.2014 23:20, Brendan Kearney wrote:
  i am using bind-dyndb-ldap outside of freeipa, and want to create
  _tcp.my-domain.com and _udp.my-domain.com subdomains.  i have tried, but
  seem to come up short and nslookup fails for the records i try to create
  in the subdomains.  some googling and searching in the wiki have not
  provided me with much go on.  below is an attempt at _tcp.my-domain.com
 
  dn: idnsName=_tcp.my-domain.com.,cn=dns,dc=my-domain,dc=com
  dnsttl: 3600
  idnsallowdynupdate: FALSE
  idnsallowsyncptr: FALSE
  idnsname: _tcp.my-domain.com.
  idnssoaexpire: 604800
  idnssoaminimum: 86400
  idnssoamname: server.my-domain.com.
  idnssoarefresh: 10800
  idnssoaretry: 900
  idnssoarname: root.server.my-domain.com.
  idnssoaserial: 1
  idnsupdatepolicy: grant MY-DOMAIN.COM krb5-self * A;
  idnszoneactive: TRUE
  nsrecord: server.my-domain.com.
  objectclass: top
  objectclass: idnsZone
  objectclass: idnsRecord
 
  what is the correct way to create a subdomain?
 
 First of all, do you really want to create *subdomains* for _tcp and _udp or 
 do you just need to create couple records like _ldap._tcp in a existing 
 domain? It is very unusual to create separate subdomains for _tcp and _udp.
 
 I'm attaching small snippet which shows how to add _ldap._tcp SRV record to 
 existing domain ipa.example.
 
 Please be so kind and send us information mentioned on
 https://fedorahosted.org/bind-dyndb-ldap/wiki/BugReporting#a3.Whatweneedtoknow
 
 We would like to know how users use bind-dyndb-ldap, which LDAP server is 
 used 
 outside FreeIPA and so on.
 
 Have a nice day!
 
 ___
 Freeipa-users mailing list
 Freeipa-users@redhat.com
 https://www.redhat.com/mailman/listinfo/freeipa-users

What distribution you use? Fedora
Which distribution version you use? Fedora 20, with latest updates
Which architecture you use? x86_64 on a qemu VM

What plugin version you use? bind-dyndb-ldap-3.5-1.fc20.x86_64
Do you use bind-dyndb-ldap as part of FreeIPA installation? no, using
openldap-servers-2.4.39-2.fc20.x86_64
Which version of BIND you use? bind-9.9.4-11.P2.fc20.x86_64

Please provide dynamic-db section from configuration
file /etc/named.conf
dynamic-db my-domain.com {
library ldap.so;
arg uri ldap://127.0.0.1/;;
arg base cn=dns,dc=my-domain,dc=com;
arg auth_method simple;
arg bind_dn cn=Manager,dc=my-domain,dc=com;
arg password *;
arg psearch no;
// arg serial_autoincrement yes;
arg sync_ptr yes;
arg dyn_update yes;
arg connections 2;
arg cache_ttl 300;
arg verbose_checks yes;
};

Do you have some other text based or DLZ zones configured? no
Do you have some global forwarders configured in BIND configuration
file? no

Do you have some settings in global configuration object in LDAP?
dn: cn=dns,dc=my-domain,dc=com
cn: dns
idnspersistentsearch: FALSE
idnszonerefresh: 30
objectclass: top
objectclass: nsContainer
objectclass: idnsConfigObject

without a doubt i want to use subdomains (or subzones, if that the
correct term) for _tcp and _udp.  kerberos, kerberos-adm,
kerberos-master, kpasswd, ldap, nfs4, wpad and ntp are the SRV records i
want to manage, and having them in the regular forward zone  is not as
clean, neat and organized as i want to be.  also, i may want to have
forward subdomains (sub.my-domain.com, for example, with
testhost.sub.my-domain.com as an A record).

the example included in the package did have a similar example on how to
put a SRV into the zone, but again, i want to manage those records with
a subdomain (or subzone, if that is the correct term).

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

[Freeipa-users] best practices for subdomains

2014-03-01 Thread Brendan Kearney

i am using bind-dyndb-ldap outside of freeipa, and want to create
_tcp.my-domain.com and _udp.my-domain.com subdomains.  i have tried, but
seem to come up short and nslookup fails for the records i try to create
in the subdomains.  some googling and searching in the wiki have not
provided me with much go on.  below is an attempt at _tcp.my-domain.com

dn: idnsName=_tcp.my-domain.com.,cn=dns,dc=my-domain,dc=com
dnsttl: 3600
idnsallowdynupdate: FALSE
idnsallowsyncptr: FALSE
idnsname: _tcp.my-domain.com.
idnssoaexpire: 604800
idnssoaminimum: 86400
idnssoamname: server.my-domain.com.
idnssoarefresh: 10800
idnssoaretry: 900
idnssoarname: root.server.my-domain.com.
idnssoaserial: 1
idnsupdatepolicy: grant MY-DOMAIN.COM krb5-self * A;
idnszoneactive: TRUE
nsrecord: server.my-domain.com.
objectclass: top
objectclass: idnsZone
objectclass: idnsRecord

what is the correct way to create a subdomain?

thank you,

brendan

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

Re: [Freeipa-users] No $ORIGIN directive in bind-dyndb-ldap

2013-10-23 Thread Brendan Kearney

 Do you plan to use FreeIPA command line interface or not?
 
 With FreeIPA, you can create equivalent records with this set of commands:
 $ ipa dnszone-add bpk2.com
 $ ipa dnsrecord-add bpk2.com _kerberos --txt-rec=...
 etc.
 
 Those commands allow you to create almost equivalent data in LDAP. This 
 doesn't work for you?
 
 Please note that dnsrecord-add command contains zone name (as the first 
 argument), so the FQDN can be constructed from the first and second argument.

i am using bind-dyndb-ldap without FreeIPA, or 389.  It is on Fedora,
with  OpenLDAP and a bunch of steps to get it working.  i am using
phpLdapAdmin to administrate the ldap instance and have created the
needed configs in ldap, using the existing sample ldif as a guide.

 
 DNS zone is represented by LDAP object which contains all other named in the 
 zone:
 idnsname=bkp2.com,cn=dns,dc=ipa,dc=test
 
 Each name inside particular zone is represented by own LDAP object:
 idnsname=_kerberos, idnsname=bkp2.com,cn=dns,dc=ipa,dc=test
 
 As a result, FQDN can be constructed for each relative name in the zone 
 simply 
 by concatenating second and first idnsname components.
 
 Is it now clearer why bind-dyndb-ldap don't have equivalent of $ORIGIN?

no.  you say that the FQDN can be constructed by stinging together 2 of
the values in the DN, but neither bind, nor the bind-dyndb-ldap
plug-in are doing that.

  attached is my forward zone (frozen before copying data, so that the jnl
  entries were written out).
 
  the desired outcome is to have zones configured so that unqualified
  queries are looked up locally and return properly, if appropriate,
  before being forwarded to any forwarders or via the hints to the roots
  or whatever is configured to be done with a record that does not have a
  locally authoritative entry.
 
 AFAIK 'unqualified' names are purely client-side thing. I belive that all 
 names have to be expanded to FQDN *before* the query is sent to any DNS 
 server. (See search directive in /etc/resolv.conf.)
 

and there are no conceivable scenarios where an unqualified query could
ever get to the bind server?  regardless of opinions on how
frequent/infrequent it could happen, the fact is that this is an
entirely legitimate scenario that improperly fails with an error.

  while zytrax does have good articles, the reference i provided is
  directly out of the bind admin guide, and likely a more authoritative
  voice on the subject.
 
 I agree. Please note that both sources say the same information, just in 
 other 
 words.
 
  i have validated that when no $ORIGIN directive is set, a query using
  the short name will fail when looked up locally, and will either be
  forwarded or recursively searched for.  the examples i provided go
  against bind+bind-dyndb-ldap, and the short name query fails.  doing the
  same lookups against my straight bind instance, using the attached zone
  file, gives authoritative responses for both short and FQDN queries.
 
 I belive that your zone file will be perfectly functional if you remove 
 origin 
 completely. You will have to replace name for SOA record.

it does not matter what will or will not work with my zones.  what i am
trying to account for is lookups failing against bind when using the
bind-dyndb-ldap backend and a short name is specified.  since the
$ORIGIN directive is written into RFC, why is it electively being
dropped, resulting in a broken implementation because of the lack of
compliance?

 $ diff -u bpk2.com.db.orig bpk2.com.db.noorigin
 --- bpk2.com.db.orig  2013-10-23 09:09:47.568113243 +0200
 +++ bpk2.com.db.noorigin  2013-10-23 09:10:09.347112464 +0200
 @@ -1,6 +1,5 @@
 -$ORIGIN .
   $TTL 3600   ; 1 hour
 -bpk2.com IN SOA  server.bpk2.com. root.server.bpk2.com. (
 +@IN SOA  server.bpk2.com. root.server.bpk2.com. (
   21684  ; serial
   10800  ; refresh (3 hours)
   3600   ; retry (1 hour)
 @@ -9,7 +8,6 @@
   )
   NS  vpn.bpk2.com.
   NS  server.bpk2.com.
 -$ORIGIN bpk2.com.
   $TTL 600; 10 minutes
   _kerberos   TXT BPK2.COM
   $TTL 5  ; 5 seconds
 
 
 I assume that your zone definition in named.conf looks like:
  zone bpk2.com. IN {
  type master;
  file bpk2.com.db;
  };
 
 As a result, default origin bpk2.com. is appended to all names in zone file 
 - and that is it.
 
 Do not forget to bump serial and check server logs if the new zone file was 
 loaded correctly ...
 
 Have a nice day!
 


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

[Freeipa-users] No $ORIGIN directive in bind-dyndb-ldap

2013-10-22 Thread Brendan Kearney

list,

i am trying to setup BIND to use the DynDB LDAP backend, and have found
that the $ORIGIN directive is not used or documented for use with the
backend.

the use case is the for the $ORIGIN directive is to handle unqualified
queries.  Below is an example of what happens without the $ORIGIN
directive set in a zone:

[brendan@test ~]$ nslookup server 127.0.0.1
Server:  127.0.0.1
Address:   127.0.0.1#53

** server can't find server: SERVFAIL

[brendan@test ~]$ nslookup server.my-domain.com 127.0.0.1
Server:  127.0.0.1
Address:   127.0.0.1#53

Name:   server.my-domain.com
Address: 192.168.1.1

the below is the BIND Admin Reference Manual entry for the $ORIGIN
directive.

The $ORIGIN Directive

Syntax: $ORIGIN domain-name [comment] 

$ORIGIN sets the domain name that will be appended to any unqualified
records. When a zone is first read in there is an implicit $ORIGIN
zone_name. (followed by trailing dot). The current $ORIGIN is appended
to the domain specified in the $ORIGIN argument if it is not absolute. 

$ORIGIN example.com.
WWW CNAME   MAIN-SERVER

is equivalent to 

WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.

would a Request For Enhancement be needed or should a bug be filed for this 
missing functionality?

thank you,

brendan kearney

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

Re: [Freeipa-users] No $ORIGIN directive in bind-dyndb-ldap

2013-10-22 Thread Brendan Kearney

my config uses bind and bind-dyndb-ldap to host zone data in ldap.  i am
trying to achieve the equivalent directives and configuration of bind
+bind-dyndb-ldap that i have in straight bind.

attached is my forward zone (frozen before copying data, so that the jnl
entries were written out).

the desired outcome is to have zones configured so that unqualified
queries are looked up locally and return properly, if appropriate,
before being forwarded to any forwarders or via the hints to the roots
or whatever is configured to be done with a record that does not have a
locally authoritative entry.

while zytrax does have good articles, the reference i provided is
directly out of the bind admin guide, and likely a more authoritative
voice on the subject.

i have validated that when no $ORIGIN directive is set, a query using
the short name will fail when looked up locally, and will either be
forwarded or recursively searched for.  the examples i provided go
against bind+bind-dyndb-ldap, and the short name query fails.  doing the
same lookups against my straight bind instance, using the attached zone
file, gives authoritative responses for both short and FQDN queries.
$ORIGIN .
$TTL 3600   ; 1 hour
bpk2.comIN SOA  server.bpk2.com. root.server.bpk2.com. (
21684  ; serial
10800  ; refresh (3 hours)
3600   ; retry (1 hour)
604800 ; expire (1 week)
3600   ; minimum (1 hour)
)
NS  vpn.bpk2.com.
NS  server.bpk2.com.
$ORIGIN bpk2.com.
$TTL 600; 10 minutes
_kerberos   TXT BPK2.COM
$TTL 5  ; 5 seconds
cache   A   192.168.25.1
A   192.168.50.1
ceton   A   192.168.200.1
$TTL 3600   ; 1 hour
desktop A   192.168.1.60
$TTL 1800   ; 30 minutes
TXT 004f797684e9ec50c37966ab6377f6e5c6
$TTL 3600   ; 1 hour
dhcp01  CNAME   server
dhcp02  CNAME   vpn
edge1037A   192.168.3.1
TXT 31f8a6da151fb3fc048a6e3dbcd4099896
HP001560497B44  CNAME   printer
inspire A   192.168.2.145
$TTL 1800   ; 30 minutes
TXT 3105220f898df9aa1cecba75583223a0e2
$TTL 3600   ; 1 hour
iphone  A   192.168.2.146
TXT 318d91a7366c7a0cbd8ac4a8cf5f11f2f8
ipsec   A   192.168.52.1
$TTL 600; 10 minutes
kerberosA   192.168.25.1
A   192.168.50.1
$TTL 3600   ; 1 hour
laptop  A   192.168.1.139
$TTL 1800   ; 30 minutes
TXT 002a031452f258ef236a2463b272372ad6
$TTL 3600   ; 1 hour
ldapA   192.168.37.3
ldap-master CNAME   server
ldap1   CNAME   server
ldap2   CNAME   vpn
modem   A   192.168.100.1
music   CNAME   desktop
ncsiCNAME   server
ns01CNAME   vpn
ns02CNAME   server
ntp CNAME   vpn
printer A   192.168.1.3
TXT 316f7731238b38ada102f07b426eb98a95
$TTL 600; 10 minutes
proxy   A   192.168.37.1
proxy1  CNAME   server
proxy2  CNAME   vpn
router  CNAME   router-vlan254
$TTL 3600   ; 1 hour
router-ipmi A   192.168.253.3
$TTL 600; 10 minutes
router-vlan1A   192.168.1.254
router-vlan2A   192.168.2.254
router-vlan25   A   192.168.25.254
router-vlan253  A   192.168.253.254
router-vlan254  A   192.168.254.254
router-vlan3A   192.168.3.254
router-vlan37   A   192.168.37.254
router-vlan50   A   192.168.50.254
router-vlan52   A   192.168.52.254
server  A   192.168.25.1
server-ipmi A   192.168.253.1
server-old  A   192.168.1.1
switch  A   192.168.254.253
wpad.tcpTXT service: wpad:!http://www.bpk2.com:80/wpad.dat;
SRV 0 0 80 server
$TTL 3600   ; 1 hour
testA   192.168.1.169
$TTL 1800   ; 30 minutes
TXT 00b6f6a38a5caaab7be5bdc35d2d3e7acc
$TTL 600; 10 minutes
tproxy  CNAME   server
vpn A   192.168.50.1
vpn-ipmiA   192.168.253.2
wifi-g  A   192.168.1.253
wifi-guest  A   192.168.3.253
wifi-n  A

46 matches

Mail list logo