Network drives fail to connect error 1208 and System error 2148073478

We had a problem where a Windows 2012 R2 Domain Controller would not browse the shares of another Windows 2012 R2 WorkGroup Server. We kept getting error 1208 and then we tried to force a mapping to share and received System error 2148073478

This problem is caused by the “Secure Negotiate” feature that was added to SMB 3.0 for Windows Server 2012 and Windows 8. This feature depends upon the correct signing of error responses by all SMBv2 servers, including servers that support only protocol versions 2.0 and 2.1. Some third-party file servers and other Windows Systems not on a domain may not not return a signed error response. Therefore, the connection fails.

We had this issue with a Windows 2012 R2 Domain Controller trying to connect to a Windows 2012 workgroup server share.

The Domain Controller had the local network set to Public and not Private, We had to change this by running a few PoSh commands.

 

Get-NetConnectionProfile

This gives us the index numbers for each interface then we find the interface marked public and change it to Private by running the PoSh command

Set-NetConnectionProfile -InterfaceIndex 10 -NetworkCategory Private

Change the InterfaceIndex number to the number of your interface.

 

Next we need to low the security level for SMB so that we can allow the connection to complete.

To do this we Edit the registry and change the value of  RequireSecureNegotiate to zero

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters" RequireSecureNegotiate -Value 0 -Force

Once that has completed you will now be able to access your network shares on other NAS servers or Windows systems.

 

Hope this helps someone out there, Enjoy!

Cubert

PassPort – Password manager plugin for LabTech

passport-600

PassPort is a password manager for plugin LabTech that leverages several applications to query Windows systems for passwords saved in Web Browsers, Instant Messengers, Network (VPN) and Dialup accounts and local email accounts and imports the information back into the LabTech database. You can then access this information inside of LabTech under the computer console on each PC.

 

website-view

 

 

 

im-view

 

 

 

email-view

 

 

configure-view

 

 Version 1.0.1 now available for download

download

 

 

 

 

 

 

We leverage several apps from Nirsoft to collect the password information and include up to date versions with our zip file download. Nirsoft tools can be found here at  http://www.nirsoft.net/

 

We use MailPassView:

Mail PassView is a small password-recovery tool that reveals the passwords and other account details for the following email clients: 

  • Outlook Express
  • Microsoft Outlook 2000 (POP3 and SMTP Accounts only)
  • Microsoft Outlook 2002/2003/2007/2010/2013 (POP3, IMAP, HTTP and SMTP Accounts)
  • Windows Mail
  • Windows Live Mail
  • IncrediMail
  • Eudora
  • Netscape 6.x/7.x (If the password is not encrypted with master password)
  • Mozilla Thunderbird (If the password is not encrypted with master password)
  • Group Mail Free
  • Yahoo! Mail – If the password is saved in Yahoo! Messenger application.
  • Hotmail/MSN mail – If the password is saved in MSN/Windows/Live Messenger application.
  • Gmail – If the password is saved by Gmail Notifier application, Google Desktop, or by Google Talk.

 

We use WebBrowserPassView:

WebBrowserPassView is a password recovery tool that reveals the passwords stored by the following Web browsers: Internet Explorer (Version 4.0 – 11.0), Mozilla Firefox (All Versions), Google Chrome, Safari, and Opera. This tool can be used to recover your lost/forgotten password of any Website, including popular Web sites, like Facebook, Yahoo, Google, and GMail, as long as the password is stored by your Web Browser.

  • This utility works on any version of Windows, starting from Windows 2000, and up to Windows 8, including 64-bit systems. Older versions of Windows (Windows 98/ME) are not supported, because this utility is a Unicode application.
  • Currently, WebBrowserPassView cannot retrieve the passwords if they are encrypted with a master password. Support for master password will probably be added in future versions.
  • Currently, WebBrowserPassView cannot retrieve passwords from external hard-drive. Support for that might be added in future versions.
  • On Internet Explorer 7.0-9.0, the passwords are encrypted with the URL of the Web site, so WebBrowserPassView uses the history file of Internet Explorer to decrypt the passwords. If you clear the history of Internet Explorer, WebBrowserPassView won’t be able to decrypt the passwords.
  • On Google Chrome – passwords originally imported from Internet Explorer 7.0-9.0, cannot be decrypted.

 

We use DialupPassView:

This utility enumerates all dialup/VPN entries on your computers, and displays their logon details: User Name, Password, and Domain. You can use it to recover a lost password of your Internet connection or VPN. This utility works under Windows 2000, Windows XP, Windows 2003/2008, Windows Vista, and Windows 7. The passwords are revealed only if you log on to the computer with administrator privileges.


We use MessenPass:

MessenPass is a password recovery tool that reveals the passwords of the following instant messenger applications:

  • MSN Messenger
  • Windows Messenger (In Windows XP)
  • Windows Live Messenger (In Windows XP/Vista/7)
  • Yahoo Messenger (Versions 5.x and 6.x)
  • Google Talk
  • ICQ Lite 4.x/5.x/2003
  • AOL Instant Messenger v4.6 or below, AIM 6.x, and AIM Pro.
  • Trillian
  • Trillian Astra
  • Miranda
  • GAIM/Pidgin
  • MySpace IM
  • PaltalkScene
  • Digsby

MessenPass can only be used to recover the passwords for the current logged-on user on your local computer, and it only works if you chose the remember your password in one of the above programs. You cannot use this utility for grabbing the passwords of other users.

 

 

 

NUT – Network Utilization Testing Plugin for LabTech

header

NUT uses IPerf to test between 2 endpoints. When launching a scan with NUT we send commands to both systems to start the IPerf executable. The Host side and the Client side sessions are sent start up commands and the client is then pointed to the host to run the configured scan options. Once the scan is complete the results are returned to the plugin console menu.

The Host side must have firewall access on the port and protocol you select (default is 5001 and TCP). You will also need to supply a FQDN or routable IP address for the host system to allow the client to locate the host system across the internet and to connect. 

You can select TCP or UDP protocols and how long to run the test from the config menu.

 

launchwindow

 

 

In version 1.0.1 we are forcing the host side to be one system under client 1. We are using our LT server as the host side and have opened up ports to allow UDP and TCP testing on port 5001. You can select any system to be a host just remember to make sure to allow firewall access to host and that host has a external FQDN or IP to allow access from other locations.

In version 1.0.2 we added the servers at any clients location to be added to the Servers side of the IPerf testing. Fixed a could minor display issues.

Version 1.0.2

 

download

Buffer Bloat, a minis to the TCP protocol

Today I would like to take a minute of your time and talk about Bandwidth usage and a little known  phenomenon called Buffer Bloat.

 

What is Buffer bloat and what does it effect?

 

Buffer bloat is the product whereby excess buffering of packets inside the network causes high latency and jitter, as well as reducing the overall network throughput. Buffer bloat occurs when a network link becomes congested, causing packets to become queued in the buffer of a router or switch. As traffic passes from one router to another this buffering can become amplified. Amplification of Buffer bloat happens as each router segment buffers the netflows, the more router segments between the endpoints the larger the bloat can grow. The problem is caused mainly by router and switch manufacturers making incorrect assumptions and buffering packets for too long in cases where they should be dropped. Dropping packets is not always a bad thing. TCP is built so that when packets are dropped the protocol slows the transmission down. Transmission speeds up and slows down until it finds an equilibrium equal to the speed of the link. However, for this to work the packet drops must occur in a timely manner and buffering packets negates this process.

 

In a network buffer (router memory), packets are queued before being transmitted and in the problematic situation packets are only dropped if the buffer is full. With the advent of cheap RAM router manufactures have been adding more and more RAM to their systems allowing for larger and larger buffers. On older routers, buffers were fairly small so they filled quickly and therefore packets began to drop shortly after the link became saturated, the TCP protocol could adjust, and the issue wouldn’t become apparent. On newer routers buffers have become large enough to hold several megabytes of data, which translates to 10 seconds or more at a 1 Mbit/s line rate.

 

The problem is not limited to just TCP, these problems also affects other protocols. All packets passing through a simple buffer implemented as a single queue will experience the same delay, so the latency of any connection that passes through a filled buffer will be affected, this includes protocols like ICMP and UDP.  If you have read this please send me a email back, I would like to see how many of us out there read this far.

 

Want to learn more about Buffer bloat and how it effect endpoints and company networks? Please visit this article on Buffer bloat at http://gettys.wordpress.com/2010/12/03/introducing-the-criminal-mastermind-bufferbloat/

 

 

[Kaseya Agent Procedure] Mac OSX Diagnostic data collection scripts

Collect Application, Network, Firewall, Ethernet and Diagnostic information from Mac OSX

Download Here -> MacOSX Diagnostics

Cubert (Me) has been tasked with learning and creating useful scripts for Mac OSX systems. Here are some of the first scripts to come out. Our techs requested after the first week using the tools in Kaseya what would help make job just a bit easier and they reported back wanting some basic information stored in Kaseya that keeps them from having to access system to confirm settings.

 

That spawned on a quick set of scripts that go out and collect the following information and stores it in a text file inside Kaseya available in the “Get File” area inside LiveConnect -> Agent Data Select Get File tab or during a hover over a orb when pop out information window shows up you can click “Get File”. Each file is named based on test run and makes for quick access to Applications and firewall settings.

Enjoy

Cubert  😎