Re: [OmniOS-discuss] cifs connectivity to DC gets lost

[Geoff Nordli]

On 16-05-30 07:24 PM, Gordon Ross wrote:

On Tue, May 24, 2016 at 6:52 PM, Geoff Nordli  wrote:

On 16-05-24 03:41 PM, Geoff Nordli wrote:

I just upgraded a server from OI to OmniOS-r151018.

I am having a few issues with the connectivity to AD.

I was able to join the domain no problem, but then the domain is getting
disconnected and after several hours I need to join the domain again.

May 24 15:25:12 stor1 idmap[472]: [ID 849457 daemon.error]   >
:::172.16.100.10 rc=0
May 24 15:25:12 stor1 idmap[472]: [ID 778215 daemon.error] DC name
dc1.domain.ca != 172.16.100.10?
May 24 15:25:12 stor1 idmap[472]: [ID 884951 daemon.notice] Configuration
changed
May 24 15:25:12 stor1 idmap[472]: [ID 452651 daemon.error] adutils:
ldap_lookup_init failed
May 24 15:25:12 stor1 idmap[472]: [ID 884951 daemon.notice] Configuration
changed
May 24 15:25:13 stor1 smbd[15085]: [ID 511178 daemon.notice] Failed to
establish NETLOGON credential chain with DC: 172.16.100.10 (UNSUCCESSFUL)
May 24 15:25:13 stor1 smbd[15085]: [ID 714496 daemon.notice] The machine
account information on the domain controller does not match the local
storage.
May 24 15:25:13 stor1 smbd[15085]: [ID 777225 daemon.notice] To correct
this, use 'smbadm join'
May 24 15:25:13 stor1 smbd[15085]: [ID 527292 daemon.notice] failed to
establish NETLOGON credential chain
May 24 15:25:13 stor1 smbd[15085]: [ID 505820 daemon.notice]  with server
172.16.100.10 for domain domain.ca (UNSUCCESSFUL)

time is synced between the two machines.

When I issue the join, I am able to get things connected again.

any thoughts?


Pulled from the idmap log:

adutils: ldap_lookup_init, host 172.16.100.10
LDAP: 172.16.100.10:3268: Local error
172.16.100.10: Local error
172.16.100.10: additional info: SASL(-1): generic failure: GSSAPI Error:
Unspecified GSS failure.  Minor code may provide more information (Server
not found in Kerberos database)
adutils: ldap_lookup_init failed
unable to discover Domains in the Forest

You figured it out.  Kerberos can only authenticate with a named host,
and the log message above say that idmap/libadutils is trying to use
ldap+gssapi+kerberos to authenticate with a DC specified only by IP
address.
That's never going to work...


Good to know.  That must have gotten set somewhere when I was trying 
different things.


Right now the:

kpasswd_server is set to a host name.
pdc is set to an IP address.

This configuration seems to be working OK.

thanks,

Geoff




___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Backup CIFS Server

[Michael Rasmussen]

On Tue, 31 May 2016 11:33:22 -0400
Steven Ford  wrote:

> 
> Should I somehow configure them to have the same kerberos keys? Is there a
> way to dumb down kerberos to behave like it used to? Would it be a bad idea
> to dumb down kerberos in this way?
> 
On windows you use ktpass.exe to generate keytab files:
https://technet.microsoft.com/en-us/library/cc753771(v=ws.11).aspx
Check parameter /out

On Unix like systems the command is ktutil:
http://web.mit.edu/kerberos/krb5-1.12/doc/admin/admin_commands/ktutil.html

The generated keytab file can be distributed to any number of hosts and
enables the beholder of the keytab to create a security context with
the AD without username and password either as a client or a server so
you should keep safe.

Typical client use: To get a service token (identify and authorize) to
a server/service.

Typical server use: To verify and validate service tokens from clients.

-- 
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael  rasmussen  cc
http://pgp.mit.edu:11371/pks/lookup?op=get=0xD3C9A00E
mir  datanom  net
http://pgp.mit.edu:11371/pks/lookup?op=get=0xE501F51C
mir  miras  org
http://pgp.mit.edu:11371/pks/lookup?op=get=0xE3E80917
--
/usr/games/fortune -es says:
There are only two kinds of tequila.  Good and better.


pgpywYP3jZU2J.pgp
Description: OpenPGP digital signature
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] LSI3108

[Linda Kateley]

I have worked with the 20.00.04.00 and it has worked very well. But the 
07 has had problems. All on freebsd or freenas. Haven't tested with omni.


If anyone has the sata 6gb firmware sitting around version 20.00.04.00 
would love to get my hands on it



linda

On 5/23/16 3:50 PM, Eric Sproul wrote:

On Mon, May 23, 2016 at 4:18 PM, Dan McDonald  wrote:

And if you do, make sure it's version 19 or lower.  The IT firmware > 19 is 
known to be flaky.  Check the illumos list archives for details on why.

We may want to revisit that advice-- I've noticed that LSI/Avago have
revised v20 firmware several times, presumably to fix bugs.  Their
support downloads currently show "20.00.07.00" available for download.
I haven't had a chance to try that one yet, but I do have some dev
systems running 20.00.04.00 without any apparent issues.  These are
direct-attach configurations, i.e. no expanders.

Eric
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss


___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Backup CIFS Server

[Dale Ghent]

> On May 31, 2016, at 11:33 AM, Steven Ford  wrote:
> 
> Hello,
> 
> I have two Omnios storage servers, a primary and a backup. Users authenticate 
> via Active Directory.
> 
> Since updating to r151018, kerberos seems to be a little pickier when 
> allowing clients to connect. Before, if my secondary took over the primary's 
> IP, connections made with the primary's domain name to the secondary came 
> through fine. Now, they are rejected with the following error:
> 
> smbd: krb5ssp: gss_accept_sec_context, mech=0xfcaa0160, major=0x7, 
> minor=0x25ea101
> smbd:  krb5: No principal in keytab matches desired name
> 
> Rejecting requests addressed to domain names that are not its own seems like 
> the proper thing to do, so I'm curious if anybody else is using Omnios as a 
> backup server meant to operate in the primary's place.
> 
> Should I somehow configure them to have the same kerberos keys? Is there a 
> way to dumb down kerberos to behave like it used to? Would it be a bad idea 
> to dumb down kerberos in this way?

Generally, yes, both servers should probably have identical keytabs which 
contain each other's specific principals, since one is expected to act like the 
other at some point (ie, in a failover scenario) ... if I'm understanding your 
situation correctly.

/dale



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] Backup CIFS Server

[Steven Ford]

Hello,

I have two Omnios storage servers, a primary and a backup. Users
authenticate via Active Directory.

Since updating to r151018, kerberos seems to be a little pickier when
allowing clients to connect. Before, if my secondary took over the
primary's IP, connections made with the primary's domain name to the
secondary came through fine. Now, they are rejected with the following
error:

smbd: krb5ssp: gss_accept_sec_context, mech=0xfcaa0160, major=0x7,
minor=0x25ea101
smbd:  krb5: No principal in keytab matches desired name

Rejecting requests addressed to domain names that are not its own seems
like the proper thing to do, so I'm curious if anybody else is using Omnios
as a backup server meant to operate in the primary's place.

Should I somehow configure them to have the same kerberos keys? Is there a
way to dumb down kerberos to behave like it used to? Would it be a bad idea
to dumb down kerberos in this way?

Any input is greatly appreciated.

Thank you,

Steve
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss