I had the opportunity to assist on a project to migrate the mainframe-based Mincom Information Management System (MIMS) to a set of HP UNIX servers at Cyprus-Amax Minerals, a Fortune 200 mining company based in Englewood, CO., between 1994 and 1997. The project was expected to save Cyprus-Amax millions of dollars. Electronic Data Systems (EDS) had the primary responsibility for the project but this later shifted to Andersen Consulting as the project was not meeting expectations while under EDS. The project called for a gradual migration of one or two mine-sites over to the UNIX platform. A serious performance issue surfaced after only a very few sites were transitioned. I resolved the performance issue after identifying the root cause to be a bug in the HP-UX operating system. Some of the credit goes to a man who introduced me to a Network General Sniffer/Analyzer. The remaining credit goes to long tedious hours of network packet-level captures and analysis.
You should never write passwords or PINs down on paper nor should you keep them stored in a text file, Word document, or Excel spreadsheet. Additionally, you should never use the same password at more than one place or web site because doing so will provide a hacker easy access to everything if he/she gains access to your favorite password. I will now explain how you can securely keep your passwords and PINs with you at all times and within easy reach whether you are using your iPad, Android tablet, Windows phone, PC, notebook, MacBook, Linux machine, or smartphone.
When attempting to configure my Cisco Adaptive Security Appliance (ASA) 5505 firewall for VPN connections from my Droid, I found a number of sites that provided information but none that worked perfectly. Part of the problem may be that my ASA is not running the latest version of the IOS. The IOS is 7.2(3) and the Droid is currently running 2.3.6.
I developed a Windows service a couple of years ago that rids dormant user objects from Active Directory. It was a fairly simple service that did what it needed to do and took into consideration the quirks of Microsoft's Active Directory Domain structure such as when users authenticate, they do so against a single domain controller with that timestamp being stored instantly on just that DC. Eventually this timestamp gets replicated to other domain controllers but that can take up to a couple of weeks.
I recently had to add additional functionality to the service so that it would clean up AD accounts referenced from an Oracle database too. Rather than having to install the Oracle SQL*Net client on the Windows server where the service runs (which could be one of the DCs), I decided to call a web service running on a web server when performing the cleanup against the Oracle database. Within the logic executed by the Windows service, I generally place a boolean variable so that the service knows if it is already running or not each time the timer fires. If it is already running, the logic is skipped until the next time it is set to fire. Adding a call to a web service caused the logic to run once but after that it failed to run again because it thought the timer from the last firing was still being processed.
Applications these days should be using secure LDAP (LDAPS) or Transport Layer Security (TLS) for authentication and authorization against a domain controller (DC). This provides an encrypted connection for data to traverse between a client, which could be a web server, and the DC. As with most encryption schemes that use digital certificates, the server certificate on the DC must be valid and not expired. An expired certificate on the DC will cause new connection attempts to the DC from clients to fail. In my experience, the clients will not try to connect to a secondary DC - so users begin seeing error messages. This all occurs even though the autoenrollment process provided the DC a replacement certificate some 42 days prior to expiration of the current certificate.
:: Next >>