Posts Tagged ‘passwords’

Spin passwords using Apple Remote Desktop

Monday, February 18th, 2013

We routinely need to change our administrative passwords on multiple computers as part of our security policy. Since we already have remote access to many of our Mac OS X computers through Apple Remote Desktop (ARD), changing that administrator password is quick and simple.

First, a short shell script:

#!/bin/bash
# Change an account's password

ACCOUNT="ladmin"
PASSWORD="MyNewP@55w0rd"
/usr/bin/dscl . passwd /Users/$ACCOUNT $PASSWORD

if [ $? = 0 ] ; then
echo "Password reset."
else
echo "Password not reset."
fi

In ARD, click the Send UNIX Command button and paste the script into the top field. Choose to run this command as a specific user and specify root.

Send UNIX Command

From the Template drop down menu in the upper right corner select Save as Template… and save these settings with a descriptive name such as Spin ladmin password.

Save as template

To use and reuse this template, select the workstations with the old account password and click the Send UNIX Command button in ARD’s toolbar. Choose the Spin ladmin password template from the Template drop down menu. Adjust the account name and password accordingly in the script and then click the Send button.

ARD can spin dozens or hundreds of account passwords in just a few seconds without having to know the original.

Changing Passwords on Windows Computers

Tuesday, April 7th, 2009

For a Domain Password:
1. Go to Active Directory Users and Computers
2. Locate user account
3. Change Password for user account
4. Wait 15 minutes for Changes to propagate in large domain with more than 2 DCs
5. Done

Local Password Change on Windows Computers on a Domain:
1. Create batch file with following script:

net user usernamethatyouwantmakechangesto newpassword

2. Edit/Create GPO for OU that has computers in question
3. Place the script as Computer startup/shutdown script GPO
4. Wait for computer GPO to propagate, and users to shutdown/startup later that evening.
5. Done

Stand-alone Workstations:
1. Ensure Workstations are XP Pro (wont work on XP Home – you’ll have to use sneakernet for password changes)
2. Ensure Simple File Sharing is TURNED OFF (if not, then Sneakernet)
3. Get PsPasswd http://technet.microsoft.com/en-us/sysinternals/bb897543.aspx
4. Make a list of all windows computers on your network, and save it to a file (a computer on each line)
5. run: pspasswd @file -u localadministrator -p password username newpassword
6. Done

Ensure the credentials you are changing are not being used for any services (On Server and Workstation):
1. Start > run > services.msc
2. Click on “Standard “Tab
3. Sort by “Log On As”
4. Note which ones are being used by non system accounts. Ensure your changes are not going to effect them. If they are, please consider making separate service user accounts for the services in question, or change the password for the service as well.
a) Get to the Properties of the service
b) Click on the Log On tab
c) Enter in the correct changed password, and confirm it.

Copy protecting PDF files in Preview

Tuesday, July 15th, 2008

Apple’s Preview application does not respect the copy protection policies created by Acrobat. Therefore, we need to use Preview to set the security policy.

The following are step by step instructions for enabling copy protection in Preview for PDF files.

1) Open the PDF in Preview.
2) From the File menu, select Print…
3) Click the PDF drop down button and choose “Save as PDF…”
4) Click Security Options… and check the “Require password to copy text, images and other content” check box.
5) Enter a password to protect the security settings and click OK.
6) Rename (if required) and save the PDF.

The security policies created by Preview are respected by Acrobat – though they cannot be modified in Acrobat.

Migrating CommuniGate Pro Mail Servers

Wednesday, September 12th, 2007

Communigate is a great mail server that is probably one of the easiest programs to move to another server. This is due to the fact that all it’s information is stored in flat files that you simply have to move from one place to another to activate or deactivate. If only Exchange was this easy!

The following is an overview of the steps involved in migrating a Communigate server from one OSX host to another. These are the 3 basic steps

1. Backup the Communigate settings and user databases 2. Install Communigate onto the new machine 3. Unpack and move the communigate files to the appropriate location

Here is a detailed step-by-step way to move a communigate install from one machine to another.

1. On the original mail server open a terminal and become root > sudo su

2. Next we should stop the CGServer so that it isn’t writing to the files as we back them up. Note: those are backticks below NOT single quotes. The backtick is usually left of the number 1 on the keyboard > kill `cat /var/Communigate/ProcessID`

3. Now we backup the files. This command places the archive at the root of the boot drive. > tar -zcvf /CommunigateBackup.tar.gz /var/Communigate

4. Copy CommunigateBackup.tar.gz to the new machine any way you please. I’ll use scp here. > scp /CommunigateBackup.tar.gz 318admin@newmailhost.local:/

5. Go to the new machine, open a terminal, become root and unpack the archive > sudo su > tar -zxvf /CommunigateBackup.tar.gz

6. Install the same communigate version as was on the the old box and reboot. It MAY work without the same version but I don’t recommend it. If you don’t know the version that was running on the old server, maybe it crashed, you can find out by running this command: > grep SYSTEM /Communigate/SystemLogs/* | grep started | awk ‘{print $5}’ | sort | uniq

7. Once the server is installed we should stop it so that there isn’t any file corruption while we restore. > kill `cat /var/Communigate/ProcessID`

8. Now we remove the current empty installation of communigate > cd /var > rm -rf CommuniGate Or if you’re like me and don’t like to rm -rf stuff as root > mv CommuniGate Communigate.old

9. Now simply move the backed up database to it’s intended destination > mv /CommuniGate /var/

10. Reboot and you’re done! You’ll notice that everything copies over, the license, the accounts, the passwords. This can be done in about 15 minutes once you get the hang of it!

FileMaker / XML Exploits Security Concerns

Tuesday, May 1st, 2007

When running FileMaker Custom Web publishing, it should be considered whether or not External Authentication via a domain should be used for the FileMaker system due to this exploit which will allow a savvy tech to grab domain userIDs and passwords to the entire domain:

An XML document fragment is loaded into the request-query parameter in the following grammar:




]
Note The query information is defined to be in the namespace fmq=”http://www.filemaker.com/xml/query”. Make sure you include a declaration of the fmq namespace in the element at the start of your XSLT stylesheet. See “About namespaces and prefixes for FileMaker XSLT stylesheets” on page 55.

For example, suppose you want to access the query commands and query parameters in this request:
http://192.168.123.101/fmi/xsl/my-stylesheet.xsl?-db=products&-lay=saIes&-grammar=fmresultset&-token.1=abc123 &-findall

If you include the statement before the template section, the Web Publishing Engine will store this XML document fragment in that parameter:
abcl23 < /query>

You can then use the request-query parameter to access the value of a token that was passed in a URL by using an XPath expression. For example:
$request-query/fmq:query/fmq:parameter[@name = '-token.l']

Obtaining client information
You can use the following FileMaker XSLT parameters to obtain information from the Web Publishing Engine about a web client’s IP address, user name, and password:


Include these parameter statements in your XSLT stylesheet before the top element.
These parameters provide the web user’s credentials when a stylesheet programmatically loads additional password-protected XML documents. See “Loading additional documents” on page 61. The web user must provide the user name and password initially via the HTTP Basic Authentication dialog box. See “When web users use Custom Web Publishing to access a protected database” on page 19.

For more information and examples of using these three FileMaker XSLT parameters, see the FileMaker XSLT Extension Function Reference.

This information is excerpted from the XSLT Reference database.

This FileMaker XSLT parameter provides the web client’s IP address.
Note: needs to be inserted before the top element. For example, this:

returns this:
Client IP: [your browser machine's IP address]

This FileMaker XSLT parameter provides the web client’s user name. You can use the parameter if your need to provide the web user’s credentials when programmatically loading additional password-protected XML documents processing, the original request.

When accessing a password protected database, you must provide a username and password within a URL. The syntax as is defined in HTTP standard is:

http://username:password@host/fmi/xml/ [Filemaker XML grammar name]. xml?query_string

Note: needs to be inserted before the top element. For example, in order to obtain the layout information from the source database, you can use client-user-name and password in the following manner.


This FileMaker XSLT parameter provides the web client’s password. You can use the parameter if your need to provide the web user’s credentials when programmatically loading additional password-protected XML documents while processing the original request.

When accessing a password protected database, you must provide a username and password within a url. The syntax as is defined in HTTP standard is:

http://username:password@host/fmi/xml/ [Filemaker XML grammar name]. xml?query_string

Note: needs to be inserted before the top element, For example, in order to obtain the layout information from the source database, you can use client-user-name and password in the following manner.



Tags: , , , , , , , ,
Posted in Directory Services, FileMaker, Security, Web Development | Comments Off

Script to Change Passwords in Mac OS X

Tuesday, July 11th, 2006

Changing a password in Mac OS X with a script is a straight forward process. Here is a script that will do so. Just replace the put currentpasswordhere in with the desired password and the 318admin with the name of the account you wish to change the password for.

#!/bin/bash

#Changes da password for the 318admin

password=”putcurrentpasswordhere”

/usr/bin/dscl . passwd /Users/318admin “$password”
status=$?

if [ $status == 0 ]; then
echo “Password was changed successfully.”
elif [ $status != 0 ]; then
echo “An error was encountered while attempting to change the password. /usr/bin/dscl exited $status.”
fi

exit $status

Pull All Passwords from CommuniGate Pro

Wednesday, March 15th, 2006

To see all passwords for every account on a communicate server:

sudo find /var/Communigate -name account.settings | xargs grep Password

If you just want to see the passwords for just the main domain then it looks like this

sudo find /var/Communigate/Accounts -name account.settings | xargs grep Password

Or if you are looking to just see the passwords for a sub domain then it looks like this

sudo find /var/Communigate/Domains/domain.com -name account.settings | xargs grep Password

Password Security

Thursday, May 26th, 2005

Logging onto most network resources requires the use of a password. Before passwords are sent over networks they are encrypted. Many different variables and algorithms are used to encrypt passwords. The most common method of encrypting passwords before they are sent over a network uses the seconds and minutes fields of file modification time stamps to build variables.

The system doesn’t use the time stamp as a variable directly, but uses them to generate hashes. A hash is a number generated from a string of text. The hash is smaller than the text itself and is generated by a formula in such a way that it is extremely unlikely that some other text would produce the same hash value. Hash values are typically 160 bits in length.

To increase security, hashes are broken up into segments, known as a message digest. These segments are sent over the network in a stream, or the actual data being transferred between two systems. A hash is a one-way function so it will not produce the same message digest from two different inputs. Kerberos uses the date and time stamps of two systems as inputs, which is one reason it is important for systems communicating using Kerberos to keep their clocks in sync. All of this helps ensure the infeasibility of reversing encryption.

Although it is infeasible it is not impossible to break encryption schemes. The NTHash standard of security used by Windows employs a password encryption scheme that simply combines hashes. The NTHash method of password encryption has been exploited. OS X, as with UNIX and Linux, uses a 12-bit string of random numbers to create a more secure hash. This 12-bit string of characters is known as a salt. The use of a 12-bit salt requires brute force attempts to crack encryption will take 4,096 times longer by taking more resources.

Using nonstandard ASCII characters such as !, #, @, *, etc. helps to increase password security as does keeping as up-to-date as possible with security patches. Using Kerberos helps to keep the encryption process as secure as possible due to salted hashes. Another security improvement with Kerberos is that Kerberos creates a ticket upon successful authentication. This ticket is used to access resources across all the servers sharing a common information database such as Open Directory and Active Directory.

In a Kerberos environment passwords don’t have to be sent over the network each time a resource is being accessed. Reducing the frequency of password usage and handling passwords more effectively makes Kerberos a strong weapon in the Network Administrators arsenal. The use of LDAP databases such as Open Directory makes network management easier and more secure.