[Freeipa-users] Re: Sub-zone client fails to install, GSS authentication pre-auth issues

2019-03-13 Thread Callum Smith via FreeIPA-users 
Dear Alexander,

Golden! We are in business - all puzzle pieces are in place so thank you very 
much for ongoing stamina with this. I'll write this all up so that someone else 
might take some value from it in the future.

Thank you again.

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 13 Mar 2019, at 11:02, Alexander Bokovoy 
mailto:aboko...@redhat.com>> wrote:

On ke, 13 maalis 2019, Callum Smith wrote:
Dear Alexander,

The last small wrinkle, setting the server options is fine and works
well, but the DNS record creation still doesn't work. I see it queries
the SOA record and then appears to use that as the server to send the
changes to.

I tried to set the SOA records for the virt.$domain realm, but it
doesnt seem to overwrite the top-level SOA record: ipa dnszone-mod 
virt.in.bmrc.ox.ac.uk. --name-server ipa-a --admin-email ipa-a I note that 
admin-email appears to be the option that actually changes
the record returned here, which was unexpected for me.
There are three levels of overrides here:

- /etc/named.conf can have 'fake_mname' defined
- 'ipa dnsserver-*' commands allow to define per-server override with
ipa dnsserver-mod  --soa-mname-override 
- DNS zone SOA mname value

If you have SOA mname overridden in the 'ipa dnsserver-show', it will
override whatever is set in the zone. This is to allow DNS location
specific updates to be localized to that location's DNS server.

If you want to control it fully from the DNS zone settings, remove
fake_mname from the /etc/named.conf and from the dnsserver's record:

ipa dnsserver-mod  --soa-mname-override=

(--soa-mname-override= sets it to empty value, meaning removal)


--admin-email in the zone should not be affecting SOA mname at all. I
suspect you saw it act conflated with the first two overrides.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Sub-zone client fails to install, GSS authentication pre-auth issues

2019-03-13 Thread Callum Smith via FreeIPA-users 
Dear Alexander,

The last small wrinkle, setting the server options is fine and works well, but 
the DNS record creation still doesn't work. I see it queries the SOA record and 
then appears to use that as the server to send the changes to.

I tried to set the SOA records for the virt.$domain realm, but it doesnt seem 
to overwrite the top-level SOA record:
ipa dnszone-mod virt.in.bmrc.ox.ac.uk. --name-server ipa-a --admin-email ipa-a
I note that admin-email appears to be the option that actually changes the 
record returned here, which was unexpected for me.

Trying to understand as much as possible from the documentation where possible, 
but still not quite there. IS there a way of forcing only the virt.$domain SOA 
record to be returned, or specifically remove the top level ipa-a.$domain 
record from the virt.$domain sub-zone SOA record somehow?

;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  0
;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
;; UPDATE SECTION:
virt-test.virt.in.bmrc.ox.ac.uk. 0 ANY  A

Outgoing update query:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:  61088
;; flags:; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
;859519045.sig-ipa-a.in.bmrc.ox.ac.uk. ANY TKEY

;; ADDITIONAL SECTION:
859519045.sig-ipa-a.in.bmrc.ox.ac.uk. 0 ANY TKEY gss-tsig. 1552471501 
1552471501 3 NOERROR 688 
YIICrAYJKoZIhvcSAQICAQBuggKbMIICl6ADAgEFoQMCAQ6iBwMFACAA 
AACjggGKYYIBhjCCAYKgAwIBBaES
GxBJTi5CTVJDLk9YLkFDLlVLoigw 
JqADAgEDoR8wHRsDRE5TGxZpcGEtYS5pbi5ibXJjLm94LmFjLnVro4IB 
OzCCATegAwIBEqEDAgECooIBKQSCASWh1n7sjwfpXDidKWGk8HSALBBW 
OwjtcqBJAGcS7yB5YGKzb4t3LUQFPXhzmZAxhZGTrkg+YLRJ3Ysty4AI 
HY1Tu465eJ0yPIOAxwVrhlQXBrs6T7K8OqyjN/rOO9KLhLMjTLz76x3S 
m5u8FE/L0FuTM3uF53qg2l00y4hjsztaDAsKFjL4vZALLDY796tGBDS0 
C8RybVcdVGeoe5L7IrHG14hTd1ppMXaGuFcIOLlEuJHW0m+YjZHlQWBT 
HYAPVKJqgBOrRiqKIVkeTBSyvUMhAG5YNMKHOtmtfBbr3hyh3xb0yRlT 
NakBI9TRSdulBkfP4ONGjnhg48huUgsaiuNl/WzdDNvzz3qepbJU8zVE 
d/B/NM5mNDmaUzYVhAnPdfb2ht6YaaSB8zCB8KADAgESooHoBIHlXbse 
XPn5DwGyQy8HWW4lwny7PrJTLmnDczg7OjSkWLsgsA9c2Ok7IBO1pRZB 
Q1DK48TZ09vEpU9nTULdKmciqikdKV7Zi50afJXVc79wGaDOhHdGByzo 
KhnZy8kDgciN9BYTJ6se7Sd+f6agZ9Fh5t5cDb4kk2LUE9bVKERqrE1D 
CgASPFqxYm60GmOOSJDlVevYAycHfmy1DFcsCJOGYAiXNWDYSxP13bhe 
DwTlhvXPOjxXhwhQxWwz+E8aNHCHEuniT1+iTHVi5xgsU98qi489Deta 
SocvV0sI1eKMoalIe0TXIw== 0


2019-03-13T10:06:41Z DEBUG stderr=Reply from SOA query:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id:  26845
;; flags: qr aa rd ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;virt-test.virt.in.bmrc.ox.ac.uk. INSOA

;; AUTHORITY SECTION:
virt.in.bmrc.ox.ac.uk.  0   IN  SOA ipa-a.in.bmrc.ox.ac.uk. 
ipa-a.virt.in.bmrc.ox.ac.uk. 1552471476 3600 900 1209600 3600

Found zone name: virt.in.bmrc.ox.ac.uk
The master is: ipa-a.in.bmrc.ox.ac.uk
start_gssrequest
send_gssrequest
; Communication with 10.141.247.129#53 failed: timed out
Reply from SOA query:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:  62319
;; flags: qr ra; QUESTION: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;859519045.sig-ipa-a.in.bmrc.ox.ac.uk. ANY TKEY

;; ANSWER SECTION:
859519045.sig-ipa-a.in.bmrc.ox.ac.uk. 0 ANY TKEY gss-tsig. 0 0 3 BADKEY 0  0

Reply from SOA query:
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id:   1248
;; flags: qr ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;sig-ipa-a.in.bmrc.ox.ac.uk.ANY TKEY

response to SOA query was unsuccessful

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk<mailto:cal...@well.ox.ac.uk>

On 12 Mar 2019, at 17:08, Alexander Bokovoy 
mailto:aboko...@redhat.com>> wrote:

On ti, 12 maalis 2019, Callum Smith via FreeIPA-users wrote:
Dear Alexander,

We already have the correct _ldap._tcp.virt.$domain in place, and the
discovery at the start of ipa-client-install is working correctly, it
discovers the correct information and installs based on that: Discovery was 
successful!
Client hostname: virt-test.virt.in.bmrc.ox.ac.uk
Realm: IN.BMRC.OX.AC.UK
DNS Domain: virt.in.bmrc.ox.ac.uk
IPA Server: ipa-b.virt.in.bmrc.ox.ac.uk
BaseDN: dc=in,dc=bmrc,dc=ox,dc=ac,dc=uk

But it is further into the process where it goes a bit wrong. I've
attached two files krb5trace and ipaclient-installer.log so that we're
not confusing the previous woes.
The difference is that during install the temporary krb5.conf written pins you
down to a specific IPA master. This is done for the purpose to avoid
replication issues if a different master was chosen at a different stage
of the install process.

Later, the actual krb5.conf written to /etc/krb5.conf does not include
that master because installation options weren't forcing us to stick to
a specific master. At this point selection of the KDCs is left to krb5
library. Actual order of service locator tries

[Freeipa-users] Re: Sub-zone client fails to install, GSS authentication pre-auth issues

2019-03-12 Thread Callum Smith via FreeIPA-users 
Dear Alexander,

We already have the correct _ldap._tcp.virt.$domain in place, and the discovery 
at the start of ipa-client-install is working correctly, it discovers the 
correct information and installs based on that:
Discovery was successful!
Client hostname: virt-test.virt.in.bmrc.ox.ac.uk
Realm: IN.BMRC.OX.AC.UK
DNS Domain: virt.in.bmrc.ox.ac.uk
IPA Server: ipa-b.virt.in.bmrc.ox.ac.uk
BaseDN: dc=in,dc=bmrc,dc=ox,dc=ac,dc=uk

But it is further into the process where it goes a bit wrong. I've attached two 
files krb5trace and ipaclient-installer.log so that we're not confusing the 
previous woes.

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 12 Mar 2019, at 16:03, Alexander Bokovoy 
mailto:aboko...@redhat.com>> wrote:

On ti, 12 maalis 2019, Callum Smith wrote:
Yep you're not wrong, one of our IPA replica was being evil and
spitting errors. That replica is destined for the bin anyway so i've
not worried about it. All of the kerberos issues have now gone away -
except one which is more of a question than anything. Is it intentional
that the sub-zone _kerberos._tcp SRV records are ignored and only the
top level SRV records are used. We were hoping that defining
_kerberos._tcp in .virt.in.bmrc.ox.ac.uk would work and over-ride the
_kerberos._tcp SRV records in .in.bmrc.ox.ac.uk

I have a feeling this behaviour is only in the installer however.
Installer uses _ldap SRV records to discover IPA masters. This is
documented in the manual page for ipa-client-install.

You can also pass --domain virt.in.bmrc.ox.ac.uk and then clients will
use this one to discover servers and use them. I guess you'll need to
add _kerberos TXT record there with 'IN.BMRC.OX.AC.UK' to properly glue
Kerberos clients but LDAP SRV records should just work.


Another (smaller) issue is that the DNS record creation as part of
`ipa-client-install` isn't working. I'm having trouble finding where to
look for the error:

Found zone name: virt.in.bmrc.ox.ac.uk
The master is: ipa-a.in.bmrc.ox.ac.uk
start_gssrequest
send_gssrequest
; Communication with 10.141.247.129#53 failed: timed out
Authoritative server is not available, thus failing to communicate with
it. I don't think it will be possible to fix this as you are running the
very same servers as dual network ones and we don't have DNS views that
would rewrite IP addresses of the authoritative servers.


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland



krb5trace
Description: krb5trace


ipaclient-install.log
Description: ipaclient-install.log
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Sub-zone client fails to install, GSS authentication pre-auth issues

2019-03-12 Thread Callum Smith via FreeIPA-users 
Yep you're not wrong, one of our IPA replica was being evil and spitting 
errors. That replica is destined for the bin anyway so i've not worried about 
it. All of the kerberos issues have now gone away - except one which is more of 
a question than anything. Is it intentional that the sub-zone _kerberos._tcp 
SRV records are ignored and only the top level SRV records are used. We were 
hoping that defining _kerberos._tcp in .virt.in.bmrc.ox.ac.uk would work and 
over-ride the _kerberos._tcp SRV records in 
.in.bmrc.ox.ac.uk

I have a feeling this behaviour is only in the installer however.

Another (smaller) issue is that the DNS record creation as part of 
`ipa-client-install` isn't working. I'm having trouble finding where to look 
for the error:

2019-03-12T14:43:39Z DEBUG The DNS query name does not exist: 
virt-test.virt.in.bmrc.ox.ac.uk.
2019-03-12T14:43:39Z WARNING Hostname (virt-test.virt.in.bmrc.ox.ac.uk) does 
not have A/ record.
2019-03-12T14:43:39Z DEBUG IP check failed: cannot use loopback IP address 
127.0.0.1
2019-03-12T14:43:39Z DEBUG IP check failed: cannot use loopback IP address ::1
2019-03-12T14:43:39Z DEBUG IP check successful: 10.141.17.1
2019-03-12T14:43:39Z DEBUG IP check failed: cannot use link-local IP address 
fe80::546f:67ff:fe51:1c%eth0
2019-03-12T14:43:39Z DEBUG IP check successful: 10.141.17.1
2019-03-12T14:43:39Z DEBUG IP check failed: cannot use link-local IP address 
fe80::546f:67ff:fe51:1c%eth0
2019-03-12T14:43:39Z DEBUG Searching for an interface of IP address: 10.141.17.1
2019-03-12T14:43:39Z DEBUG Testing local IP address: 127.0.0.1/255.0.0.0 
(interface: lo)
2019-03-12T14:43:39Z DEBUG Testing local IP address: 10.141.17.1/255.255.240.0 
(interface: eth0)
2019-03-12T14:43:39Z DEBUG Writing nsupdate commands to 
/etc/ipa/.dns_update.txt:
2019-03-12T14:43:39Z DEBUG debug

update delete virt-test.virt.in.bmrc.ox.ac.uk. IN A
show
send

update delete virt-test.virt.in.bmrc.ox.ac.uk. IN 
show
send

update add virt-test.virt.in.bmrc.ox.ac.uk. 1200 IN A 10.141.17.1
show
send

2019-03-12T14:43:39Z DEBUG Starting external process
2019-03-12T14:43:39Z DEBUG args=/usr/bin/nsupdate -g /etc/ipa/.dns_update.txt
2019-03-12T14:45:23Z DEBUG Process finished, return code=1
2019-03-12T14:45:23Z DEBUG stdout=Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  0
;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
;; UPDATE SECTION:
virt-test.virt.in.bmrc.ox.ac.uk. 0 ANY  A

Outgoing update query:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:  55036
;; flags:; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
;3005929322.sig-ipa-a.in.bmrc.ox.ac.uk. ANY TKEY

;; ADDITIONAL SECTION:
3005929322.sig-ipa-a.in.bmrc.ox.ac.uk. 0 ANY TKEY gss-tsig. 1552401823 
1552401823 3 NOERROR 688 
YIICrAYJKoZIhvcSAQICAQBuggKbMIICl6ADAgEFoQMCAQ6iBwMFACAA 
AACjggGKYYIBhjCCAYKgAwIBBaE
SGxBJTi5CTVJDLk9YLkFDLlVLoigw 
JqADAgEDoR8wHRsDRE5TGxZpcGEtYS5pbi5ibXJjLm94LmFjLnVro4IB 
OzCCATegAwIBEqEDAgECooIBKQSCASX4L4yJ9gPwWyHU5szTktPPJP+G 
Hjf/Bzworzuk1ODfJ5k/rG35UYurnk1KB0FI
RYaeblQ8CPyYZ9eAmo1l WiPHFT+GwVtiUN6nhiPno5cQway4I5BCBOAQBEuxJd96GGqMhZYZLzWZ 
EomtIyl3JGL7GcuXFV62S9Dwg3FXsME3XYkBGrCQXHgXX35Yq0sh5sWI 
JM/XDPfbTxDHonLc+l/FSCyXB1KlOBc0v9KGX02V3aPlc
NssV2xvk8y/ Nt/nyCI8VtzIa/6fSy/ZDpdwCkLqF2TbXY3ans6x1YbtS6GXIQtB3SFr 
n5PLZ+D/s6iHDHw7x4+q2on9+zlytLJahdoJLUO6/Zbr0MQrJPTjGmEb 
/RMySXyzEFz/evVVwlApnGlYY8ToIKSB8zCB8KADAgESooHoBIHl/v
gZ 5/9qdzXOnRNBsmlgXU4viWXwbncZgQJ3E14rZOybp3/V9CVon0TjA4W4 
+DsvWTeFiW9TO8ItLEsy/Am5phN3JemwPbSzYlZjUUovAKcCUg19Bn9o 
T6U2uopI38PxIIW7hieiQbcwu2thzjmVZCTLzl/ecxzHPhfWYbgJAz3T WLsYS+
7TvVBU7UwYrbYb6Pbs3jF6VZCkEGRUz6DrQ8ukoL/hjBNcJ7uP 
MtNz9IVk61Monet/6fAT/EqIgvBYTGXySclw4/x8q2VxShtZ9NwT104+ 
eMijav0t8wsxeoL0HIq67w== 0


2019-03-12T14:45:23Z DEBUG stderr=Reply from SOA query:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id:  21780
;; flags: qr aa rd ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;virt-test.virt.in.bmrc.ox.ac.uk. INSOA

;; AUTHORITY SECTION:
virt.in.bmrc.ox.ac.uk.  0   IN  SOA ipa-a.in.bmrc.ox.ac.uk. 
hostmaster.virt.in.bmrc.ox.ac.uk. 1552319704 3600 900 1209600 3600

Found zone name: virt.in.bmrc.ox.ac.uk
The master is: ipa-a.in.bmrc.ox.ac.uk
start_gssrequest
send_gssrequest
; Communication with 10.141.247.129#53 failed: timed out
Reply from SOA query:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:  26740
;; flags: qr ra; QUESTION: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;3005929322.sig-ipa-a.in.bmrc.ox.ac.uk. ANY TKEY

;; ANSWER SECTION:
3005929322.sig-ipa-a.in.bmrc.ox.ac.uk. 0 ANY TKEY gss-tsig. 0 0 3 BADKEY 0  0

Reply from SOA query:
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id:  22380
;; flags: qr ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;sig-ipa-a.in.bmrc.ox.ac.uk.ANY TKEY

response to SOA query was unsuccessful

2019-03-12T14:45:23Z DEBUG nsupdate

[Freeipa-users] Re: Sub-zone client fails to install, GSS authentication pre-auth issues

2019-03-12 Thread Callum Smith via FreeIPA-users 
So I've just re-run the client install to avoid the noise of krb5kdc.log (just 
as to why the timestamps don't match) and this is the entire block:

Mar 12 12:08:48 ipa-b.in.bmrc.ox.ac.uk krb5kdc[1967](info): AS_REQ (8 etypes 
{18 17 20 19 16 23 25 26}) 10.141.17.1: NEEDED_PREAUTH: 
ad...@in.bmrc.ox.ac.uk for 
krbtgt/in.bmrc.ox.ac...@in.bmrc.ox.ac.uk,
 Additional pre-authentication required
Mar 12 12:08:48 ipa-b.in.bmrc.ox.ac.uk krb5kdc[1967](info): closing down fd 11
Mar 12 12:08:48 ipa-b.in.bmrc.ox.ac.uk krb5kdc[1967](info): AS_REQ (8 etypes 
{18 17 20 19 16 23 25 26}) 10.141.17.1: ISSUE: authtime 1552392528, etypes 
{rep=18 tkt=18 ses=18}, ad...@in.bmrc.ox.ac.uk 
for 
krbtgt/in.bmrc.ox.ac...@in.bmrc.ox.ac.uk
Mar 12 12:08:48 ipa-b.in.bmrc.ox.ac.uk krb5kdc[1967](info): closing down fd 11
Mar 12 12:08:48 ipa-b.in.bmrc.ox.ac.uk krb5kdc[1967](info): TGS_REQ (8 etypes 
{18 17 20 19 16 23 25 26}) 10.141.17.1: ISSUE: authtime 1552392528, etypes 
{rep=18 tkt=18 ses=18}, ad...@in.bmrc.ox.ac.uk 
for 
ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk
Mar 12 12:08:48 ipa-b.in.bmrc.ox.ac.uk krb5kdc[1967](info): closing down fd 11
Mar 12 12:08:48 ipa-b.in.bmrc.ox.ac.uk krb5kdc[1967](info): TGS_REQ (8 etypes 
{18 17 20 19 16 23 25 26}) 10.141.17.1: ISSUE: authtime 1552392528, etypes 
{rep=18 tkt=18 ses=18}, ad...@in.bmrc.ox.ac.uk 
for 
HTTP/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk
Mar 12 12:08:48 ipa-b.in.bmrc.ox.ac.uk krb5kdc[1967](info): closing down fd 11
Mar 12 12:08:48 ipa-b.in.bmrc.ox.ac.uk krb5kdc[1967](info): TGS_REQ (1 etypes 
{18}) 10.141.17.1: ISSUE: authtime 1552392528, etypes {rep=18 tkt=18 ses=18}, 
ad...@in.bmrc.ox.ac.uk for 
krbtgt/in.bmrc.ox.ac...@in.bmrc.ox.ac.uk
Mar 12 12:08:48 ipa-b.in.bmrc.ox.ac.uk krb5kdc[1967](info): closing down fd 11
Mar 12 12:08:48 ipa-b.in.bmrc.ox.ac.uk krb5kdc[1967](info): TGS_REQ (8 etypes 
{18 17 20 19 16 23 25 26}) 10.141.248.2: ISSUE: authtime 1552392528, etypes 
{rep=18 tkt=18 ses=18}, ad...@in.bmrc.ox.ac.uk 
for 
ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk
Mar 12 12:08:48 ipa-b.in.bmrc.ox.ac.uk krb5kdc[1967](info): closing down fd 11
Mar 12 12:08:48 ipa-b.in.bmrc.ox.ac.uk krb5kdc[1967](info): AS_REQ (8 etypes 
{18 17 20 19 16 23 25 26}) 10.141.17.1: NEEDED_PREAUTH: 
host/virt-test.virt.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk
 for 
krbtgt/in.bmrc.ox.ac...@in.bmrc.ox.ac.uk,
 Additional pre-authentication required
Mar 12 12:08:48 ipa-b.in.bmrc.ox.ac.uk krb5kdc[1967](info): closing down fd 11
Mar 12 12:08:48 ipa-b.in.bmrc.ox.ac.uk krb5kdc[1967](info): AS_REQ (8 etypes 
{18 17 20 19 16 23 25 26}) 10.141.17.1: ISSUE: authtime 1552392528, etypes 
{rep=18 tkt=18 ses=18}, 
host/virt-test.virt.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk
 for 
krbtgt/in.bmrc.ox.ac...@in.bmrc.ox.ac.uk
Mar 12 12:08:48 ipa-b.in.bmrc.ox.ac.uk krb5kdc[1967](info): closing down fd 11

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 12 Mar 2019, at 12:04, Alexander Bokovoy 
mailto:aboko...@redhat.com>> wrote:

On ti, 12 maalis 2019, Callum Smith wrote:
Dear Alexander,

No worries - here's the krb5kdc.log relevant area when you get a
moment. I understand that service aliases are relatively new to FreeIPA
so debugging them is proving to be a bit tricky.
Hm.. the log you provided does not include a line where host/virt-test...
client asks for a service ticket (TGS_REQ) to HTTP/virt-b... that
results in PROCESS_TGS response.

The log entries around that one are needed.

We're very grateful for your time - particularly when it may be taking
you away from things like implementing the Global Catalogue we're eager
for :D.
:) I wish I had time for that already. I'm trying to fix
https://pagure.io/freeipa/issue/7181 right now.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:

[Freeipa-users] Re: Sub-zone client fails to install, GSS authentication pre-auth issues

2019-03-12 Thread Callum Smith via FreeIPA-users 
Dear Alexander,

No worries - here's the krb5kdc.log relevant area when you get a moment. I 
understand that service aliases are relatively new to FreeIPA so debugging them 
is proving to be a bit tricky.

Mar 12 10:54:31 ipa-b.in.bmrc.ox.ac.uk krb5kdc[1967](info): AS_REQ (8 etypes 
{18 17 20 19 16 23 25 26}) 10.141.17.1: NEEDED_PREAUTH: 
ad...@in.bmrc.ox.ac.uk<mailto:ad...@in.bmrc.ox.ac.uk> for 
krbtgt/in.bmrc.ox.ac...@in.bmrc.ox.ac.uk<mailto:krbtgt/in.bmrc.ox.ac...@in.bmrc.ox.ac.uk>,
 Additional pre-authentication required
Mar 12 10:54:31 ipa-b.in.bmrc.ox.ac.uk krb5kdc[1967](info): closing down fd 11
Mar 12 10:54:31 ipa-b.in.bmrc.ox.ac.uk krb5kdc[1967](info): AS_REQ (8 etypes 
{18 17 20 19 16 23 25 26}) 10.141.17.1: ISSUE: authtime 1552388071, etypes 
{rep=18 tkt=18 ses=18}, ad...@in.bmrc.ox.ac.uk<mailto:ad...@in.bmrc.ox.ac.uk> 
for 
krbtgt/in.bmrc.ox.ac...@in.bmrc.ox.ac.uk<mailto:krbtgt/in.bmrc.ox.ac...@in.bmrc.ox.ac.uk>
Mar 12 10:54:31 ipa-b.in.bmrc.ox.ac.uk krb5kdc[1967](info): closing down fd 11
Mar 12 10:54:31 ipa-b.in.bmrc.ox.ac.uk krb5kdc[1967](info): TGS_REQ (8 etypes 
{18 17 20 19 16 23 25 26}) 10.141.17.1: ISSUE: authtime 1552388071, etypes 
{rep=18 tkt=18 ses=18}, ad...@in.bmrc.ox.ac.uk<mailto:ad...@in.bmrc.ox.ac.uk> 
for 
ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk<mailto:ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk>
Mar 12 10:54:31 ipa-b.in.bmrc.ox.ac.uk krb5kdc[1967](info): closing down fd 11
Mar 12 10:54:31 ipa-b.in.bmrc.ox.ac.uk krb5kdc[1967](info): TGS_REQ (8 etypes 
{18 17 20 19 16 23 25 26}) 10.141.17.1: ISSUE: authtime 1552388071, etypes 
{rep=18 tkt=18 ses=18}, ad...@in.bmrc.ox.ac.uk<mailto:ad...@in.bmrc.ox.ac.uk> 
for 
HTTP/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk<mailto:HTTP/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk>
Mar 12 10:54:31 ipa-b.in.bmrc.ox.ac.uk krb5kdc[1967](info): closing down fd 11
Mar 12 10:54:31 ipa-b.in.bmrc.ox.ac.uk krb5kdc[1967](info): TGS_REQ (1 etypes 
{18}) 10.141.17.1: ISSUE: authtime 1552388071, etypes {rep=18 tkt=18 ses=18}, 
ad...@in.bmrc.ox.ac.uk<mailto:ad...@in.bmrc.ox.ac.uk> for 
krbtgt/in.bmrc.ox.ac...@in.bmrc.ox.ac.uk<mailto:krbtgt/in.bmrc.ox.ac...@in.bmrc.ox.ac.uk>
Mar 12 10:54:31 ipa-b.in.bmrc.ox.ac.uk krb5kdc[1967](info): closing down fd 11
Mar 12 10:54:31 ipa-b.in.bmrc.ox.ac.uk krb5kdc[1967](info): TGS_REQ (8 etypes 
{18 17 20 19 16 23 25 26}) 10.141.248.2: ISSUE: authtime 1552388071, etypes 
{rep=18 tkt=18 ses=18}, ad...@in.bmrc.ox.ac.uk<mailto:ad...@in.bmrc.ox.ac.uk> 
for 
ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk<mailto:ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk>
Mar 12 10:54:31 ipa-b.in.bmrc.ox.ac.uk krb5kdc[1967](info): closing down fd 11
Mar 12 10:54:31 ipa-b.in.bmrc.ox.ac.uk krb5kdc[1967](info): AS_REQ (8 etypes 
{18 17 20 19 16 23 25 26}) 10.141.17.1: NEEDED_PREAUTH: 
host/virt-test.virt.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk<mailto:host/virt-test.virt.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk>
 for 
krbtgt/in.bmrc.ox.ac...@in.bmrc.ox.ac.uk<mailto:krbtgt/in.bmrc.ox.ac...@in.bmrc.ox.ac.uk>,
 Additional pre-authentication required
Mar 12 10:54:31 ipa-b.in.bmrc.ox.ac.uk krb5kdc[1967](info): closing down fd 11
Mar 12 10:54:31 ipa-b.in.bmrc.ox.ac.uk krb5kdc[1967](info): AS_REQ (8 etypes 
{18 17 20 19 16 23 25 26}) 10.141.17.1: ISSUE: authtime 1552388071, etypes 
{rep=18 tkt=18 ses=18}, 
host/virt-test.virt.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk<mailto:host/virt-test.virt.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk>
 for 
krbtgt/in.bmrc.ox.ac...@in.bmrc.ox.ac.uk<mailto:krbtgt/in.bmrc.ox.ac...@in.bmrc.ox.ac.uk>
Mar 12 10:54:31 ipa-b.in.bmrc.ox.ac.uk krb5kdc[1967](info): closing down fd 11

We're very grateful for your time - particularly when it may be taking you away 
from things like implementing the Global Catalogue we're eager for :D.

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk<mailto:cal...@well.ox.ac.uk>

On 12 Mar 2019, at 11:52, Alexander Bokovoy 
mailto:aboko...@redhat.com>> wrote:

On ti, 12 maalis 2019, Callum Smith via FreeIPA-users wrote:
ldap/ipa-b.virt.$domain > ldap/ipa-b.$domain
HTTP/ipa-b.virt.$domain > HTTP/ipa-b.$domain

both aliases as above - krb5trace should be in attachments on previous message.
My bad. Thanks, can you also give krb5kdc.log output from the KDC server the
client talked to?

It looks like KDC is not finding something and returning PROCESS_TGS. I
have no time to look into details right now.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Sub-zone client fails to install, GSS authentication pre-auth issues

2019-03-12 Thread Callum Smith via FreeIPA-users 
ldap/ipa-b.virt.$domain > ldap/ipa-b.$domain
HTTP/ipa-b.virt.$domain > HTTP/ipa-b.$domain

both aliases as above - krb5trace should be in attachments on previous message.

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk<mailto:cal...@well.ox.ac.uk>

On 12 Mar 2019, at 11:09, Alexander Bokovoy 
mailto:aboko...@redhat.com>> wrote:

On ti, 12 maalis 2019, Callum Smith wrote:
Dear Alexander,

It seems setting up the principal alias has gotten us to a further point down 
the line, but we're seeing other issues now.

We've moved both ldap/ and HTTP/ principals to aliases of the main
principal (the downside being we can't do an altname-based automated
certificate request - but manually issuing certificates is an ok
workaround). We're still seeing issues potentially relating to the HTTP
principal authentication though, despite it now being an alias. Any
ideas here?
>From your sentence above I'm not sure whether you made
HTTP/ipa-b.virt.$domain an alias of ldap/... or HTTP/ipa-b.$domain?

If the former, then it is not correct.

If the latter, then please show krb5 traces.



Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. 
cal...@well.ox.ac.uk<mailto:cal...@well.ox.ac.uk><mailto:cal...@well.ox.ac.uk>

On 11 Mar 2019, at 14:27, Alexander Bokovoy 
mailto:aboko...@redhat.com><mailto:aboko...@redhat.com>> 
wrote:

On ma, 11 maalis 2019, Callum Smith via FreeIPA-users wrote:
Dear IPA Gurus

I have a client that's incapable of joining the FreeIPA realm, it's in
a different DNS sub-zone but is in the same realm. I get the feeling
that there's a kerberos principal missing somewhere to get this all to
work, but I can't quite see where it might be. Simple authentication
ldapsearch using cn=Directory Manager functions perfectly well to the
ipa host in question, however anonymous binds are disabled. I'm not
clear why this wouldn't be working.
>From the above it is unclear what your problem is.

Can you show what exactly is failing? ipa-client-install is failing?
Show logs from /var/log/ipaclient-install.log. You aren't using FreeIPA
enrollment? How exactly did you try to enroll that client? Show sequence
of commands you ran.

It is not easy to help with no logs and exact steps tried.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland





--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Sub-zone client fails to install, GSS authentication pre-auth issues

2019-03-12 Thread Callum Smith via FreeIPA-users 
Dear Alexander,

It seems setting up the principal alias has gotten us to a further point down 
the line, but we're seeing other issues now.

We've moved both ldap/ and HTTP/ principals to aliases of the main principal 
(the downside being we can't do an altname-based automated certificate request 
- but manually issuing certificates is an ok workaround). We're still seeing 
issues potentially relating to the HTTP principal authentication though, 
despite it now being an alias. Any ideas here?


Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk<mailto:cal...@well.ox.ac.uk>

On 11 Mar 2019, at 14:27, Alexander Bokovoy 
mailto:aboko...@redhat.com>> wrote:

On ma, 11 maalis 2019, Callum Smith via FreeIPA-users wrote:
Dear IPA Gurus

I have a client that's incapable of joining the FreeIPA realm, it's in
a different DNS sub-zone but is in the same realm. I get the feeling
that there's a kerberos principal missing somewhere to get this all to
work, but I can't quite see where it might be. Simple authentication
ldapsearch using cn=Directory Manager functions perfectly well to the
ipa host in question, however anonymous binds are disabled. I'm not
clear why this wouldn't be working.
>From the above it is unclear what your problem is.

Can you show what exactly is failing? ipa-client-install is failing?
Show logs from /var/log/ipaclient-install.log. You aren't using FreeIPA
enrollment? How exactly did you try to enroll that client? Show sequence
of commands you ran.

It is not easy to help with no logs and exact steps tried.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland



krb5trace
Description: krb5trace


ipaclient-install.log
Description: ipaclient-install.log
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Sub-zone client fails to install, GSS authentication pre-auth issues

2019-03-11 Thread Callum Smith via FreeIPA-users 
Dear Alexander,

Some more (hopefully) helpful information with a KRB5_TRACE on while running 
ipa-client install:

ipa-client-install
WARNING: ntpd time synchronization service will not be configured as
conflicting service (chronyd) is enabled
Use --force-ntpd option to disable it and force configuration of ntpd

Discovery was successful!
Client hostname: virt-test.virt.in.bmrc.ox.ac.uk
Realm: IN.BMRC.OX.AC.UK
DNS Domain: virt.in.bmrc.ox.ac.uk
IPA Server: ipa-b.virt.in.bmrc.ox.ac.uk
BaseDN: dc=in,dc=bmrc,dc=ox,dc=ac,dc=uk

Continue to configure the system with these values? [no]: yes
Skipping synchronizing time with NTP server.
User authorized to enroll computers: admin
Password for ad...@in.bmrc.ox.ac.uk:
[7792] 1552322394.293495: ccselect module realm chose cache 
FILE:/tmp/krbccQ6OHiN/ccache with client principal 
ad...@in.bmrc.ox.ac.uk for server principal 
ldap/ipa-b.virt.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk
[7792] 1552322394.293496: Getting credentials 
ad...@in.bmrc.ox.ac.uk -> 
ldap/ipa-b.virt.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk
 using ccache FILE:/tmp/krbccQ6OHiN/ccache
[7792] 1552322394.293497: Retrieving 
ad...@in.bmrc.ox.ac.uk -> 
ldap/ipa-b.virt.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk
 from FILE:/tmp/krbccQ6OHiN/ccache with result: -1765328243/Matching credential 
not found (filename: /tmp/krbccQ6OHiN/ccache)
[7792] 1552322394.293498: Retrieving 
ad...@in.bmrc.ox.ac.uk -> 
krbtgt/in.bmrc.ox.ac...@in.bmrc.ox.ac.uk
 from FILE:/tmp/krbccQ6OHiN/ccache with result: 0/Success
[7792] 1552322394.293499: Starting with TGT for client realm: 
ad...@in.bmrc.ox.ac.uk -> 
krbtgt/in.bmrc.ox.ac...@in.bmrc.ox.ac.uk
[7792] 1552322394.293500: Requesting tickets for 
ldap/ipa-b.virt.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk,
 referrals on
[7792] 1552322394.293501: Generated subkey for TGS request: aes256-cts/6474
[7792] 1552322394.293502: etypes requested in TGS request: aes256-cts, 
aes128-cts, aes256-sha2, aes128-sha2, des3-cbc-sha1, rc4-hmac, camellia128-cts, 
camellia256-cts
[7792] 1552322394.293504: Encoding request body and padata into FAST request
[7792] 1552322394.293505: Sending request (985 bytes) to IN.BMRC.OX.AC.UK
[7792] 1552322394.293506: Resolving hostname ipa-b.virt.in.bmrc.ox.ac.uk
[7792] 1552322394.293507: Initiating TCP connection to stream 10.141.31.252:88
[7792] 1552322394.293508: Sending TCP request to stream 10.141.31.252:88
[7792] 1552322394.293509: Received answer (883 bytes) from stream 
10.141.31.252:88
[7792] 1552322394.293510: Terminating TCP connection to stream 10.141.31.252:88
[7792] 1552322394.293511: Response was from master KDC
[7792] 1552322394.293512: Decoding FAST response
[7792] 1552322394.293513: FAST reply key: aes256-cts/7B54
[7792] 1552322394.293514: TGS reply is for 
ad...@in.bmrc.ox.ac.uk -> 
ldap/ipa-b.virt.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk
 with session key aes256-cts/0013
[7792] 1552322394.293515: TGS request result: 0/Success
[7792] 1552322394.293516: Received creds for desired service 
ldap/ipa-b.virt.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk
[7792] 1552322394.293517: Storing 
ad...@in.bmrc.ox.ac.uk -> 
ldap/ipa-b.virt.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk
 in FILE:/tmp/krbccQ6OHiN/ccache
[7792] 1552322394.293519: Creating authenticator for 
ad...@in.bmrc.ox.ac.uk -> 
ldap/ipa-b.virt.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk,
 seqnum 27249405, subkey aes256-cts/2328, session key aes256-cts/0013
Unable to download CA cert from LDAP.


Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 11 Mar 2019, at 16:19, Alexander Bokovoy 
mailto:aboko...@redhat.com>> wrote:

On ma, 11 maalis 2019, Callum Smith wrote:
Locally on the IPA server I note that doing an ldapsearch using GSSAPI works, 
if i use the ldap host:
ldaps://ipa-b.in.bmrc.ox.ac.uk/
but not:
ldaps://ipa-b.virt.in.bmrc.ox.ac.uk/

Since the client can only access the network that is
ipa-b.virt.in.bmrc.ox.ac.uk it needs to be able to communicate to LDAP
via that hostname. Is this actually possible, since the TGT is _always_
going to be on ipa-b.$domain because of the nsslapd-localhost entry?
Question I

[Freeipa-users] Re: Sub-zone client fails to install, GSS authentication pre-auth issues

2019-03-11 Thread Callum Smith via FreeIPA-users 
Dear Alexander,

We're wondering that too, there's obviously a disparity between the domain that 
either end is issuing the LDAP ticket for, and the SRV records for the 
`virt.in.bmrc.ox.ac.uk` domain all point to the LDAP endpoint. Do i need 
specific SRV records for ldaps and not ldap? I earlier attached a screenshot of 
our domain setup for the VIRT subdomain.

I fear the opposite may be the case and the client is requesting the correct 
one but the ldap server is defaulting to the root domain not the subdomain.

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 11 Mar 2019, at 16:19, Alexander Bokovoy 
mailto:aboko...@redhat.com>> wrote:

On ma, 11 maalis 2019, Callum Smith wrote:
Locally on the IPA server I note that doing an ldapsearch using GSSAPI works, 
if i use the ldap host:
ldaps://ipa-b.in.bmrc.ox.ac.uk/
but not:
ldaps://ipa-b.virt.in.bmrc.ox.ac.uk/

Since the client can only access the network that is
ipa-b.virt.in.bmrc.ox.ac.uk it needs to be able to communicate to LDAP
via that hostname. Is this actually possible, since the TGT is _always_
going to be on ipa-b.$domain because of the nsslapd-localhost entry?
Question I have is why the client actually chooses ldap/ipa-b.$domain
itself? This is probably the easiest place to change since it is driven
by the DNS discovery so you can influence by whatever is put in the DNS
SRV records.


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Sub-zone client fails to install, GSS authentication pre-auth issues

2019-03-11 Thread Callum Smith via FreeIPA-users 
Locally on the IPA server I note that doing an ldapsearch using GSSAPI works, 
if i use the ldap host:
ldaps://ipa-b.in.bmrc.ox.ac.uk/
but not:
ldaps://ipa-b.virt.in.bmrc.ox.ac.uk/

Since the client can only access the network that is 
ipa-b.virt.in.bmrc.ox.ac.uk it needs to be able to communicate to LDAP via that 
hostname. Is this actually possible, since the TGT is _always_ going to be on 
ipa-b.$domain because of the nsslapd-localhost entry?

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk<mailto:cal...@well.ox.ac.uk>

On 11 Mar 2019, at 15:58, Alexander Bokovoy 
mailto:aboko...@redhat.com>> wrote:

On ma, 11 maalis 2019, Callum Smith via FreeIPA-users wrote:
Dear Alexander,

klist -kt /etc/dirsrv/ds.keytab
Keytab name: FILE:/etc/dirsrv/ds.keytab
KVNO Timestamp Principal
 - 
 1 02/11/18 12:09:17 
ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk<mailto:ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk><mailto:ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk>
 1 02/11/18 12:09:17 
ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk<mailto:ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk><mailto:ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk>
 3 08/03/19 16:11:12 
ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk<mailto:ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk><mailto:ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk>
 3 08/03/19 16:11:12 
ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk<mailto:ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk><mailto:ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk>
 4 08/03/19 16:11:44 
ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk<mailto:ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk><mailto:ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk>
 4 08/03/19 16:11:44 
ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk<mailto:ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk><mailto:ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk>
 4 08/03/19 16:25:20 
ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk<mailto:ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk><mailto:ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk>
 4 08/03/19 16:25:20 
ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk<mailto:ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk><mailto:ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk>
 1 11/03/19 10:50:01 
ldap/ipa-b.virt.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk<mailto:ldap/ipa-b.virt.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk><mailto:ldap/ipa-b.virt.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk>
 1 11/03/19 10:50:01 
ldap/ipa-b.virt.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk<mailto:ldap/ipa-b.virt.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk><mailto:ldap/ipa-b.virt.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk>
 2 11/03/19 10:50:17 
ldap/ipa-b.cloud.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk<mailto:ldap/ipa-b.cloud.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk><mailto:ldap/ipa-b.cloud.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk>
 2 11/03/19 10:50:17 
ldap/ipa-b.cloud.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk<mailto:ldap/ipa-b.cloud.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk><mailto:ldap/ipa-b.cloud.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk>
 2 11/03/19 10:50:22 
ldap/ipa-b.hpc.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk<mailto:ldap/ipa-b.hpc.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk><mailto:ldap/ipa-b.hpc.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk>
 2 11/03/19 10:50:22 
ldap/ipa-b.hpc.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk<mailto:ldap/ipa-b.hpc.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk><mailto:ldap/ipa-b.hpc.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk>

This is a bit non-standard i understand, but so far this configuration
is working ok. I guess the issue is that the ticket is being issued for
the wrong domain.
[cid:F8DF5B93-5D52-46D5-88AC-E9BEA54760FD@in.bmrc.ox.ac.uk]

I've attached a screenshot of the DNS configuration for the sub-zone.

Our intention here is to ensure that the DNS entry and host for the IPA
server within a different sub-zone and subnet resolves to a single IP
for speed. So a "host" has been created for each of the interfaces, all
of the respective kerberos principals for the host services (ldap in
this case) and then a new certificate issued with the alt names on it
to allow for LDAPS. This works well, right up until the point of GSSAPI
getting involved. There must be a piece of the puzzle we're missing
here!
Can you check in cn=config which value is set for nsslapd-localhost
attribute? This is the hostname value used by the LDAP server when it
initializes own TGT from the keytab.

It should be ipa-b.$domain to make sure that both the client
and the server are utilizing the same service principal. I suspect it is
set to ipa-b.virt.$domain and thus the issue.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

___
Fr

[Freeipa-users] Re: Sub-zone client fails to install, GSS authentication pre-auth issues

2019-03-11 Thread Callum Smith via FreeIPA-users 
>From dse.ldiff
nsslapd-localhost: ipa-b.in.bmrc.ox.ac.uk

Fairly sure this is representative of the current running configuration, as the 
node was rebooted only hours ago.

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk<mailto:cal...@well.ox.ac.uk>

On 11 Mar 2019, at 15:58, Alexander Bokovoy 
mailto:aboko...@redhat.com>> wrote:

On ma, 11 maalis 2019, Callum Smith via FreeIPA-users wrote:
Dear Alexander,

klist -kt /etc/dirsrv/ds.keytab
Keytab name: FILE:/etc/dirsrv/ds.keytab
KVNO Timestamp Principal
 - 
 1 02/11/18 12:09:17 
ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk<mailto:ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk><mailto:ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk>
 1 02/11/18 12:09:17 
ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk<mailto:ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk><mailto:ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk>
 3 08/03/19 16:11:12 
ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk<mailto:ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk><mailto:ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk>
 3 08/03/19 16:11:12 
ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk<mailto:ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk><mailto:ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk>
 4 08/03/19 16:11:44 
ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk<mailto:ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk><mailto:ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk>
 4 08/03/19 16:11:44 
ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk<mailto:ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk><mailto:ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk>
 4 08/03/19 16:25:20 
ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk<mailto:ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk><mailto:ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk>
 4 08/03/19 16:25:20 
ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk<mailto:ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk><mailto:ldap/ipa-b.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk>
 1 11/03/19 10:50:01 
ldap/ipa-b.virt.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk<mailto:ldap/ipa-b.virt.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk><mailto:ldap/ipa-b.virt.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk>
 1 11/03/19 10:50:01 
ldap/ipa-b.virt.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk<mailto:ldap/ipa-b.virt.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk><mailto:ldap/ipa-b.virt.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk>
 2 11/03/19 10:50:17 
ldap/ipa-b.cloud.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk<mailto:ldap/ipa-b.cloud.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk><mailto:ldap/ipa-b.cloud.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk>
 2 11/03/19 10:50:17 
ldap/ipa-b.cloud.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk<mailto:ldap/ipa-b.cloud.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk><mailto:ldap/ipa-b.cloud.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk>
 2 11/03/19 10:50:22 
ldap/ipa-b.hpc.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk<mailto:ldap/ipa-b.hpc.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk><mailto:ldap/ipa-b.hpc.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk>
 2 11/03/19 10:50:22 
ldap/ipa-b.hpc.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk<mailto:ldap/ipa-b.hpc.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk><mailto:ldap/ipa-b.hpc.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk>

This is a bit non-standard i understand, but so far this configuration
is working ok. I guess the issue is that the ticket is being issued for
the wrong domain.
[cid:F8DF5B93-5D52-46D5-88AC-E9BEA54760FD@in.bmrc.ox.ac.uk]

I've attached a screenshot of the DNS configuration for the sub-zone.

Our intention here is to ensure that the DNS entry and host for the IPA
server within a different sub-zone and subnet resolves to a single IP
for speed. So a "host" has been created for each of the interfaces, all
of the respective kerberos principals for the host services (ldap in
this case) and then a new certificate issued with the alt names on it
to allow for LDAPS. This works well, right up until the point of GSSAPI
getting involved. There must be a piece of the puzzle we're missing
here!
Can you check in cn=config which value is set for nsslapd-localhost
attribute? This is the hostname value used by the LDAP server when it
initializes own TGT from the keytab.

It should be ipa-b.$domain to make sure that both the client
and the server are utilizing the same service principal. I suspect it is
set to ipa-b.virt.$domain and thus the issue.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Sub-zone client fails to install, GSS authentication pre-auth issues

2019-03-11 Thread Callum Smith via FreeIPA-users 
Dear Alexander,

Sorry, yes indeed using ipa-client-install. The ipaclient-install.log should be 
attached, I can upload to dropbox if needed. Discovery happens succesfully, but 
LDAP GSSAPI authentication is failing for some reason.

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk<mailto:cal...@well.ox.ac.uk>

On 11 Mar 2019, at 14:27, Alexander Bokovoy 
mailto:aboko...@redhat.com>> wrote:

On ma, 11 maalis 2019, Callum Smith via FreeIPA-users wrote:
Dear IPA Gurus

I have a client that's incapable of joining the FreeIPA realm, it's in
a different DNS sub-zone but is in the same realm. I get the feeling
that there's a kerberos principal missing somewhere to get this all to
work, but I can't quite see where it might be. Simple authentication
ldapsearch using cn=Directory Manager functions perfectly well to the
ipa host in question, however anonymous binds are disabled. I'm not
clear why this wouldn't be working.
>From the above it is unclear what your problem is.

Can you show what exactly is failing? ipa-client-install is failing?
Show logs from /var/log/ipaclient-install.log. You aren't using FreeIPA
enrollment? How exactly did you try to enroll that client? Show sequence
of commands you ran.

It is not easy to help with no logs and exact steps tried.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] OTP + SSHKey/Certificate Authentication

2019-03-08 Thread Callum Smith via FreeIPA-users 
Dear FreeIPA Gurus,

I was wondering if it's possible to configure `sshd` such that for OTP based 
authentication the first factor could be passed as a ssh key or certificate.

So specifically: The user's password would not be required for auth, only the 
key and OTP token. Is there a magic combination of AuthenticationMethods for 
`sshd_config` that would allow this to work?

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] IPA server on multiple subzones

2019-03-05 Thread Callum Smith via FreeIPA-users 
Dear All,

We have a number of DNS sub zones in different IP subnets, and we want to 
ensure that DNS queries respond quickly and aren't waiting for timeouts. So as 
such we're thinking of putting our IPA on multiple interfaces, one in each sub 
zone, and registering the host and it's clients within that sub zone 
separately. To achieve this we need to add principal aliases for each sub zone 
to the IPA services - which appears to be working well so far, but I have a 
question: what's the best way to setup a new certificate for the web interface 
to allow SSL on the new sub zone interface. We're thinking of simply adding alt 
names to the certificate and getting a newly issued one from the local CA. 
Should we be looking to do this exclusively  with certutil or should we be 
using ipa-server-certinstall.

I hope that this makes sense and our approach isn't complete madness.

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: OTP via LDAP auth time sync

2019-02-27 Thread Callum Smith via FreeIPA-users 
Dear Rob, All,

Just to be clear, we have indeed tracked this down to another issue, and the 
OTP/LDAP timing is fine. I imagine you already knew this, but this is confirmed 
to _not_ be an issue.

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk<mailto:cal...@well.ox.ac.uk>

On 4 Feb 2019, at 22:06, Rob Crittenden 
mailto:rcrit...@redhat.com>> wrote:

Callum Smith via FreeIPA-users wrote:
Dear All,

I'm seeing issues with the time synchronisation for OTP but ONLY for
authentication through LDAP and not through kerberos. Is this even
possible or am I going down the wrong rabbit hole on this issue. The
error presents as LDAP authentication giving "ldap operation failed"
when authentication to HashiCorp Vault, configured to auth against IPA
over LDAP, if the token is slightly old.

Have you been able to define a range for "slightly old"? Is there some
latency that is causing issue?

Is anything logged in the 389-ds error log when the operations error
fires? I'm not sure which error level would help in this case, some can
be kinda spammy. Is this easily reproducible on an otherwise quiet system?

rob

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] OTP via LDAP auth time sync

2019-02-04 Thread Callum Smith via FreeIPA-users 
Dear All,

I'm seeing issues with the time synchronisation for OTP but ONLY for 
authentication through LDAP and not through kerberos. Is this even possible or 
am I going down the wrong rabbit hole on this issue. The error presents as LDAP 
authentication giving "ldap operation failed" when authentication to HashiCorp 
Vault, configured to auth against IPA over LDAP, if the token is slightly old.

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Cannot start FreeIPA master - procedure for cleaning up?

2018-11-01 Thread Callum Smith via FreeIPA-users 
Dear Rob,

Thanks for the fast reply, I think there's something really wrong with the 
hostname that's configured for the box (that'll teach me for using Ansible), 
and it's trying to auth locally when it's not running yet.

krb5kdc.log

Nov 01 18:18:59 ipa-a.in.bmrc.ox.ac.uk krb5kdc[11212](info): AS_REQ (8 etypes 
{18 17 20 19 16 23 25 26}) 192.168.1.144: CLIENT_NOT_FOUND: 
host/ipa-b.cloud.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk
 for 
krbtgt/in.bmrc.ox.ac...@in.bmrc.ox.ac.uk,
 Client not found in Kerberos database
Nov 01 18:18:59 ipa-a.in.bmrc.ox.ac.uk krb5kdc[11212](info): closing down fd 11
Nov 01 18:18:59 ipa-a.in.bmrc.ox.ac.uk krb5kdc[11212](info): AS_REQ (8 etypes 
{18 17 20 19 16 23 25 26}) 10.141.248.2: CLIENT_NOT_FOUND: 
host/ipa-b.cloud.in.bmrc.ox.ac...@in.bmrc.ox.ac.uk
 for 
krbtgt/in.bmrc.ox.ac...@in.bmrc.ox.ac.uk,
 Client not found in Kerberos database

(ipa-b.cloud.in.bmrc... doesnt exist and shouldn't - so there's a problem there 
too).

slapd/access
[01/Nov/2018:19:46:33.586518662 +] conn=1 fd=64 slot=64 connection from ::1 
to ::1
[01/Nov/2018:19:46:33.587225369 +] conn=2 fd=65 slot=65 connection from 
127.0.0.1 to 127.0.0.1
[01/Nov/2018:19:46:33.587501315 +] conn=1 op=-1 fd=64 closed - B1
[01/Nov/2018:19:46:33.592352645 +] conn=2 op=-1 fd=65 closed - B1
[01/Nov/2018:19:46:33.593372333 +] conn=3 fd=64 slot=64 connection from ::1 
to ::1
[01/Nov/2018:19:46:33.593766162 +] conn=4 fd=65 slot=65 connection from 
127.0.0.1 to 127.0.0.1
[01/Nov/2018:19:46:33.593898023 +] conn=3 op=-1 fd=64 closed - B1
[01/Nov/2018:19:46:33.599951489 +] conn=5 fd=66 slot=66 connection from ::1 
to ::1
[01/Nov/2018:19:46:33.600104933 +] conn=4 op=-1 fd=65 closed - B1
[01/Nov/2018:19:46:33.603688533 +] conn=5 op=-1 fd=66 closed error 125 
(Operation canceled) - A1

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 1 Nov 2018, at 19:11, Rob Crittenden 
mailto:rcrit...@redhat.com>> wrote:

/var/log/dirsrv/slapd-REALM/access

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Cannot start FreeIPA master - procedure for cleaning up?

2018-11-01 Thread Callum Smith via FreeIPA-users 
Dear All,

Running a FreeIPA cluster, the master has fallen over and refuses to get back 
up:

Failed to read data from service file: Unknown error when retrieving list of 
services from LDAP: Insufficient access: SASL(-4): no mechanism available: 
(Unknown authentication method)

I was wondering where the best place for logs is to get myself out of this 
hole, as it's the "super master" i'd rather not have to delete it, promote 
another, etc etc.

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Account creation via API not assigning uidNumber

2018-10-25 Thread Callum Smith via FreeIPA-users 
Dear Alexander,

You're exactly right, failure on my part to understand how the module 
underneath was parsing keyword arguments (and that the attribute had to be 
specifically omitted and not just a None value).

Thanks for your help, all working fine now.

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 25 Oct 2018, at 08:38, Alexander Bokovoy 
mailto:aboko...@redhat.com>> wrote:

On to, 25 loka 2018, Callum Smith wrote:
Dear Alexander,

The issue is not with the library (it does no validation of syntax) the
error I have provided is verbose directly from the FreeIPA API
response.

It seems the library puts some defaults that aren't accepted by the
FreeIPA API, unlike a client code we provide. Or may be that's your use
of it. More below.

How would you suggest I re-factor this code so that the error is acceptable?

Looking at the definition of 'uidnumber' parameter to user object, we
can see it has minimal value of '1' and it is optional (? at the end of
the name):

  Int('uidnumber?',
  cli_name='uid',
  label=_('UID'),
  doc=_('User ID Number (system will assign one if not provided)'),
  minvalue=1,
  ),

This means that if you wouldn't provide it in your request, it will be
automatically generated.

So a simple approach would be replace explicit addition of named
arguments by a dict and then adding that dict:

opts = {}
if options.uid:
  opts['uidnumber'] = options.uid
opts['gidnumber'] = options.primary_gid
opts['mail'] = options.mail
opts['home_directory'] = options.home_directory
opts['user_password'] = options.password
...

client.user_add(, **opts)


(client is initialised and logged in - tested and working with other calls such 
as user_show etc)

client.user_add(
  options.username,
  options.first_name,
  options.last_name,
  options.name,
  mail=options.mail,
  home_directory=options.home_directory,
  uidnumber=options.uid if options.uid else -1,
  gidnumber=options.primary_gid,
  user_password=options.password,
)
Sorry, this is not an API provided by the FreeIPA project. Please
contact authors of python-freeipa (I think it was created by OpenNode
people) and report them bugs you see there.

https://pypi.org/project/python-freeipa/


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Account creation via API not assigning uidNumber

2018-10-25 Thread Callum Smith via FreeIPA-users 
Dear Alexander,

The issue is not with the library (it does no validation of syntax) the error I 
have provided is verbose directly from the FreeIPA API response.

How would you suggest I re-factor this code so that the error is acceptable?

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk<mailto:cal...@well.ox.ac.uk>

On 24 Oct 2018, at 17:54, Alexander Bokovoy 
mailto:aboko...@redhat.com>> wrote:

On ke, 24 loka 2018, Callum Smith via FreeIPA-users wrote:
Dear Rob,

I'm using the python-freeipa library:

(client is initialised and logged in - tested and working with other calls such 
as user_show etc)

client.user_add(
options.username,
options.first_name,
options.last_name,
options.name,
mail=options.mail,
home_directory=options.home_directory,
uidnumber=options.uid if options.uid else -1,
gidnumber=options.primary_gid,
user_password=options.password,
)
Sorry, this is not an API provided by the FreeIPA project. Please
contact authors of python-freeipa (I think it was created by OpenNode
people) and report them bugs you see there.

https://pypi.org/project/python-freeipa/


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Account creation via API not assigning uidNumber

2018-10-24 Thread Callum Smith via FreeIPA-users 
Dear Rob,

I'm using the python-freeipa library:

(client is initialised and logged in - tested and working with other calls such 
as user_show etc)

client.user_add(
  options.username,
  options.first_name,
  options.last_name,
  options.name,
  mail=options.mail,
  home_directory=options.home_directory,
  uidnumber=options.uid if options.uid else -1,
  gidnumber=options.primary_gid,
  user_password=options.password,
)

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk<mailto:cal...@well.ox.ac.uk>

On 24 Oct 2018, at 13:32, Rob Crittenden 
mailto:rcrit...@redhat.com>> wrote:

Callum Smith wrote:
Dear Rob,

Running v4.5.0 (CentOS 7.4 distribution)
API version 2.228

Setting it to -1 gives:
ValidationError: invalid 'uid': must be at least 1

Need more information on what exactly it is you are doing.

rob


Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk<mailto:cal...@well.ox.ac.uk> 
<mailto:cal...@well.ox.ac.uk>

On 24 Oct 2018, at 12:47, Rob Crittenden 
mailto:rcrit...@redhat.com>
<mailto:rcrit...@redhat.com>> wrote:

Callum Smith via FreeIPA-users wrote:
Dear All,

When using the API to create an account, if I don't specify the
uidnumber I get this error:

missing attribute "uidNumber" required by object class "posixAccount"

I was expecting the uidNumber to function thus: "system will assign one
if not provided"

Am I missing something?

You need to set uidnumber to -1 to have DNA automatically assign a value
(pre v3.2 the magic number is 999).

rob



___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Account creation via API not assigning uidNumber

2018-10-24 Thread Callum Smith via FreeIPA-users 
Dear Rob,

Running v4.5.0 (CentOS 7.4 distribution)
API version 2.228

Setting it to -1 gives:
ValidationError: invalid 'uid': must be at least 1

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk<mailto:cal...@well.ox.ac.uk>

On 24 Oct 2018, at 12:47, Rob Crittenden 
mailto:rcrit...@redhat.com>> wrote:

Callum Smith via FreeIPA-users wrote:
Dear All,

When using the API to create an account, if I don't specify the
uidnumber I get this error:

missing attribute "uidNumber" required by object class "posixAccount"

I was expecting the uidNumber to function thus: "system will assign one
if not provided"

Am I missing something?

You need to set uidnumber to -1 to have DNA automatically assign a value
(pre v3.2 the magic number is 999).

rob

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Account creation via API not assigning uidNumber

2018-10-24 Thread Callum Smith via FreeIPA-users 
Dear All,

When using the API to create an account, if I don't specify the uidnumber I get 
this error:

missing attribute "uidNumber" required by object class "posixAccount"

I was expecting the uidNumber to function thus: "system will assign one if not 
provided"

Am I missing something?

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Prevent users reading other users' data from the WebUI

2018-08-01 Thread Callum Smith via FreeIPA-users 
Dear All,

Seems this has come up before but the previous fix no longer works. Is there a 
way to do this through the Roles, because it doesn't seem obvious to me 
immediately? Any help welcomed!

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/D5AMTMTZMNKEOBU3HGP6DM37D5GBBND3/